Usability Evaluation von Games - Anwendung von HCID-Methoden im Umfeld von Indie-Games
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Usability Evaluation von Games Anwendung von HCID-Methoden im Umfeld von Indie-Games Masterarbeit MAS HCID, 2017/18 Florian Westermann, Marco Malacarne, Sebastian Westhues
Danksagung
Wir bedanken uns an dieser Stelle bei folgenden Personen für die Unterstützung:
ƳƳ Dem ganzen Struckd-Team, speziell bei Silvan und Flurin, für Ihre grosse
Bereitschaft und Unterstützung. Wir danken für die zahlreichen Teilnahmen an
unseren Design Sprints und dem konstruktiven Austausch.
ƳƳ Unserem Coach Bernhard von Allmen für die wertvolle Unterstützung.
ƳƳ Bei allen Kindern welche sich für die Interviews und Usability Walkthrough zur
Verfügung gestellt haben. Sowie der Jugendarbeit Fällanden und
Robi-Spiel-Aktionen Basel, welche mit viel Engagement die User-Tests ermög-
licht haben.
ƳƳ YooApplications, RaiseNow und RandomReality für die Nutzung der Büros.
ƳƳ Lukas Schwarz für das kritische und genaue Lektorat.
2
Selbstständigkeitserklärung
Hiermit bestätigen wir,
ƳƳ dass wir die vorliegende Arbeit selbst und ohne fremde Hilfe ausgeführt haben,
ausser derjenigen, welche explizit beschrieben ist. Dazu gehört folgende
Ausnahme: Programmierung des Unity-Prototypen für den Design-Sprint 1.
Dieser Prototyp wurde durch die Struckd AG erstellt und vom Projektteam
getestet.
ƳƳ dass wir sämtliche verwendeten Quellen erwähnt und gemäss gängigen
wissenschaftlichen Regeln korrekt zitiert haben,
ƳƳ dass wir keine durch Copyright geschützten Materialien (z.B. Bilder) in dieser
Arbeit in unerlaubte Weise genutzt haben und
ƳƳ dass wir in dieser Arbeit keine Adressen, Telefonnummern und andere persönli-
che Daten von Personen, die nicht zum Kernteam gehören, publizieren.
Zürich, 31. Januar 2018 Zürich, 31. Januar 2018 Basel, 31. Januar 2018
Florian Westermann Marco Malacarne Sebastian Westhues
Impressum
Januar 2018
Vorgelegt im Rahmen des Masters of Advanced Studies in Human Computer
Interaction Design an der HSR Hochschule für Technik Rapperswil und der Univer-
sität Basel.
Projektteam Florian Westermann, Marco Malacarne und
Sebastian Westhues
Auftraggeber Struckd AG, Pfingstweidstrasse 31a, 8005 Zürich
Flurin Jenal und Silvan Bauser
Betreuer Bernhard von Allmen
Co-Referent Marc Steffen
In der vorliegenden Arbeit wird der Einfachheit halber nur die männliche Form
verwendet. Die weibliche Form ist selbstverständlich immer miteingeschlossen.
3
Management Summary
Weltweit spielen über 2,2 Milliarden Personen Games. Die UCD-Methoden und Game-Heuristik
Umsätze durchbrechen im Jahr 2017 die 100 Milliarden Der Transfer von UCD-Methoden in den Game-Kontext funk-
USD Marke. Damit gehört die Game-Industrie zu einer der tionierte mehrheitlich gut. Doch im Bereich der Definition von
am stärksten wachsenden Industrien. Spiel- bzw. Unterhal- Messzielen und der Anwendung von Evaluationsmethoden
tungs-Software unterscheidet sich von Produktsoftware zeigten sich aber deutlich die Grenzen der klassischen Me-
deutlich in der Art, wie sie herstellerseitig konzipiert, evaluiert thoden. Ausserdem erwies sich die Erstellung von testbaren
und von Benutzern angewendet wird. Die primäre Absicht Prototypen als nicht ganz trivial, da es galt ein angestrebtes
von Games liegt darin, den Spieler zu unterhalten. Spielerlebnis zu simulieren.
Anlässlich dieser Masterarbeit hat das Projektteam,
bestehend aus Florian Westermann, Marco Malacarne und Kindern zwischen 10-14 Jahren
Sebastian Westhues, untersucht, ob klassische Methoden Im Laufe dieser Arbeit setzte sich das Projektteam intensiv
aus der Evaluation von Softwareprodukten erfolgreich in mit der Altersgruppe von 10-14 Jährigen auseinander. Dabei
den Kontext der Game-Industrie transferiert werden kön- wurden in der Zielgruppe enorme Unterschiede hinsichtlich
nen. Dabei wurden die klassischen Methoden mit Heuris- kognitiven Fähigkeiten und dem Lern- und Sprachverhalten
tiken aus der Unterhaltungsbranche verbunden, und am festgestellt.
Beispiel von Struckd, einem Game-Startup aus Zürich, an-
gewendet. Seitens Struckd bestand das Interesse, mit ei- Ergebnisse
ner besseren Usability die aktuell tiefe Retention-Rate zu Über insgesamt vier Design-Iterationen wurde das Onboar-
steigern. Aus diesem Grund wurde der Fokus der Unter- ding und die Bedienung des 3D-Game-Editors bearbeitet.
suchung und Weiterentwicklung auf den Onboarding-Be- In der letzten Evaluation konnte eine deutliche Verbesse-
reich und die Bedienung des 3D-Game-Editors gelegt. rung hinsichtlich Orientierung, Bedienung und Motivation
der Testpersonen nachgewiesen werden. Trotz der positiven
Kombination Cooper mit Google Design Sprint Resultate der Arbeit möchte das Projektteam mit Nachdruck
Die Kombination der Vorgehensmodelle nach Cooper (Goal- darauf hinweisen, dass die Optimierungen noch nicht ihr vol-
Directed Design) und Knapp (Design Sprint) funktionierte les Potenzial erreicht haben. Dazu wird dem Auftraggeber
erfolgreich. Cooper erwies sich als geeignet für die Phasen empfohlen, sich weiterhin intensiv mit den Bedürfnissen und
Research, Modellierung und Requirements Engineering, da Verhalten der Zielgruppe auseinanderzusetzen.
er einerseits Raum und Methoden zum Aufbau des Domä-
nenwissens bietet und anderseits grossen Wert auf die Er-
hebung und Modellierung der Benutzer legt. Gerade letzte-
res erwies sich als zentrales Instrument in der Planung und
Durchführung des Designs. Knapps Design Sprint zeigte sich
als effektives Vorgehensmodell in der Phase des Designs.
Dies durch den starken Einbezug der Stakeholder und klar
strukturierten Abläufen von Elaboration, über Design bis hin
zum Prototyp.
4
Inhaltsverzeichnis
1. EINLEITUNG 6 4. MODELLIERUNG 30
1.1 Auftraggeber 6 4.1 Personas 32
1.2 Relevanz des Themas 8 5. REQUIREMENTS DEFINITION 35
1.3 Fragestellung 9 5.1 Einleitung 36
2. VORGEHEN & PROJEKTSETUP 10 5.2 Kontextszenarien 36
2.1 Vorgehensmodell 12 6. DESIGN 39
2.2 Vorgehensmodell und Zuweisung der Methoden 13 6.1 Design Sprint 40
2.3 Risikoanalyse 14 6.2 Design Sprint 1 44
2.4 Organisation im Team 15 6.3 Design Sprint 2 48
2.5 Projektplan 16 6.4 Design Sprint 3 52
3. RESEARCH 19 6.5 Design Sprint 4 54
3.1 Stakeholder Interview 20 7. EMPFEHLUNGEN AN DEN AUFTRAGGEBER 57
3.2 Beobachtung 21 8. FAZIT 58
3.3 Aufbau Domänenwissen 22 9. REFLEXIONEN 64
3.4 Selbstversuch mit Expert Review 24 10. LITERATURVERZEICHNIS 68
3.5 Konkurrenz Analyse 25 11. GLOSSAR 71
3.6 Analyse von Daten 26 12. ANHANG 72
3.7 Nutzer-Interviews 28
5
1. EINLEITUNG
1.1 Auftraggeber
Struckd, vor etwas mehr als zwei Jahren durch Flurin Jenal
und Silvan Bauser gegründet, gilt als eines der erfolgreichs-
ten Game-Startups der Schweiz. Während des letzten Jahres
haben sie eine Spiele-Plattform, ähnlich wie die Video-Platt-
form YouTube, für Android und iOS geschaffen, auf welcher
es möglich ist, lediglich mittels Drag & Drop und ohne Pro-
grammierkenntnisse eigene 3D-Spiele zu erstellen. Diese
Games können dann direkt auf der Plattform geteilt, gespielt
und kommentiert werden. Die Plattform ist ein Erfolg und
zählt schon über 10›000 individuell erstellte Spiele. Gemäss
Aussage der Gründer möchte man eine Zielgruppe im Alter
zwischen 8-14 Jahren ansprechen.
Die Firma finanziert sich aktuell durch Investoren und
Sponsored Content (z.B. Audi und Y&R Group), welche den
laufenden Betrieb mittelfristig sicherstellen. Struckd verfolgt
primär das Ziel eines schnellen Nutzerwachstums und einer
treuen User-Basis – als Grundlage für die geplante zukünf-
tige Monetarisierung der Plattform, welche noch nicht genau
definiert ist.
6Quelle: Alessandro Fischer
EINLEITUNG
1.2 Relevanz des Themas
Globale Situation der Gaming Branche HCI Community
Die hohe Relevanz von Games lässt sich mit Zahlen gut ver- Spiel- bzw. Unterhaltungs-Software unterscheidet sich von
anschaulichen. Weltweit spielen über 2,2 Milliarden Perso- Produktsoftware deutlich in der Art, wie sie herstellerseitig
nen Games (McDonald, 2017). Die Umsätze durchbrechen im konzipiert, evaluiert und von Benutzern angewendet wird. Die
Jahr 2017 die 100 Milliarden USD Marke. Mit einem Markt- primäre Absicht von Spielsoftware liegt darin, den Spieler zu
anteil von 42 % sind die Tablet/Mobile-Spiele das lukrativste unterhalten. Produktivitätssoftware hingegen dient als Werk-
und gleichzeitig am stärksten wachsende Segment. Die top 5 zeug, um die Aufgaben eines Benutzers zu vereinfachen und
Mobile-Games sind global für 13 % der Mobile-Game-Um- zu beschleunigen. Aus dieser Betrachtungsweise leitet zum
sätze verantwortlich. Dabei zeigt sich die Herausforderung Beispiel Lazzaro (Isbister, 2008) zwei klar differenzierte Grup-
der kleineren und Indie-Game-Studios, sich gegenüber den pen von Erlebnis-Zielsetzungen (Experience goals) ab und
marktbeherrschenden AAA (Wikipedia, 2017) Studios zu be- stellt sie einander wie folgt gegenüber:
haupten und den stetig wachsenden Erwartungen der Kon-
sumenten gerecht zu werden.
Eine klare Definition und Abgrenzung von Indie-Ga- UX goals: productivity PX goals: entertainment
me-Studios gibt es nicht. In der Branche definieren sich ƳƳ Task completion ƳƳ Entertainment
Indie-Studios dadurch, dass sie unabhängig von einem Pu- ƳƳ Eliminate errors ƳƳ Fun to overcome obstacles
blisher arbeiten, ein Team von weniger als 25 Mitarbeiter auf- ƳƳ External reward ƳƳ Intrinsic reward
weisen und nur mit kleinen Budgets auskommen. Mit dem ƳƳ Outcome-based rewards ƳƳ Process is its own reward
Erfolg der Spiele steigt auch das Interesse für Gamification, ƳƳ Intuitive ƳƳ New things to learn
zu Deutsch ‘Spielifizierung’. Elemente aus Spielen werden in ƳƳ Reduce workload ƳƳ Increases workload
neue Kontexte übertragen. Dabei werden klassische Spiel- ƳƳ Assumes technology needs ƳƳ Assumes humans need
mechanismen und Prinzipien übernommen, um die Nutzer zu to be humanized to be challenged
motivieren, Prozesse, die normalerweise monoton ablaufen,
dadurch interessant und motivierend zu gestalten.
Unterschiedliche Experience-Goals bei der User-Experience (UX) und
Player-Experience (PX). Quelle: Isbister, 2008
Bei der Betrachtung der beiden Erlebnisziele wird klar, dass
je nach Betrachtungsschwerpunkt andere Methoden zur
Anwendung gebracht werden müssen. So finden sich zum
Beispiel im klassischen Usability Testing schwerlich Metho-
den, welche zur Definition und Messung von Begrifflichkeiten
wie ‘Unterhaltung’ oder ‘Spass’ herangezogen werden kön-
nen. Ein Teil dieser Arbeit beschäftigt sich deswegen mit der
Frage, welche Evaluations-Methoden im Kontext von Spie-
len und Spiel-Erlebnissen existieren und für das vorliegende
Praxisprojekt verwendet werden können.
8EINLEITUNG
1.3 Fragestellung
1.2.1. Ziele des Auftraggebers
Verbesserung des 3D-Game-Editors Softwareprojekte. Hierfür gilt es bestehende und erprobte
Struckd versteht sich als Plattform zur Erstellung von Spie- Heuristiken aus der Spiele-Branche zu evaluieren und zu er-
len für die eigene Community. Das Herzstück bildet dabei proben, damit eine aussagekräftige Evaluation gewährleistet
der 3D-Game-Editor (kurz: Editor). Der Auftraggeber verfolgt werden kann.
zwei Ziele zu dessen Optimierung:
ƳƳ Optimierung der Usability innerhalb des Editors. Transferierbarkeit von Evaluationsmethoden
ƳƳ Benutzer sollen im Editor auf unterhaltsame, motivierende Während der Weiterbildung an der HSR wurden Methoden
Art Spiele erstellen und die Plattform mit qualitativ zur Evaluation von klassischen Softwareprojekten erlernt. Die
hochwertigem Content versorgen. vorliegenden Arbeit untersucht die Transferierbarkeit von Ex-
pert Reviews und Usability-Walkthroughs im Game-Kontext.
Steigerung der Retention-Rate
Die Optimierung des Editors soll eine direkte Steigerung der Benutzer ‘Creator’ verstehen
Kundenbindungsrate nach sich ziehen. Einen konkreten Ziel- Nach der Hypothese des Auftraggebers teilen sich die User
wert wurde nicht definiert. Die Retention-Rate ist eine Kenn- in zwei Benutzergruppen auf. Die Minderheit (Creator) erstellt
zahl, welche die Benutzertreue einer Plattform oder eines Spiele für die Mehrheit der Benutzer. Die Mehrheit (Gamer)
Services als Prozentsatz darstellt (Wikipedia, 2017). Sie wird sind reine Konsumenten der erstellten Games. In der vorlie-
im Kontext von Struckd in drei Varianten verwendet (7 Tage, genden Arbeit wird untersucht, inwiefern die Hypothese des
30 Tage, 60 Tage) und als wichtigste Kennzahl gegenüber der Auftraggebers zutrifft. Mithilfe von Beobachtungen und In-
Investoren verwendet. terviews sollen Personas modelliert und in Usertests evalu-
iert werden. Zur Erreichung der Ziele wird der Fokus aber auf
die Benutzergruppe Creator gelegt.
1.2.2. Ziele des Projektteams
In Absprache mit dem Auftraggeber wurden in dieser Arbeit 1.2.3. Abgrenzung
folgende Fokusziele gesetzt:
ƳƳ Verbesserung des Editor mit Hilfe von UCD Methoden Geräte und Plattform
ƳƳ Research und Anwendung von Evaluationsmethoden im Bei Projektstart war das Spiel nur für mobile Touch-Devices
Game-Kontext auf iOS und Android verfügbar. Eine Desktop-Version war
bei Struckd bereits in Planung und wurde während der Pro-
Die Retention-Rate als Projektziel wurde nicht übernommen, jektlaufzeit im Herbst 2017 erstmals in Form einer Beta-Ver-
da im Laufe des Projektes deutlich wurde, dass keine ver- sion veröffentlicht. Die vorliegende Arbeit fokussierte auf die
lässlichen Aussagen diesbezüglich gemacht werden können. mobile Version auf einem Smartphone und schliesst die Be-
Dies mit der Begründung, dass erstens keine genauen analy- trachtung des Spiels mit Maus und Tastatur an einem Desk-
tischen Daten verfügbar sind und dass zweitens nicht beein- top aus.
flussbare Faktoren das Messergebnis verfälschen könnten.
Anwendung
Research von Game-Usability Heuristiken Die Betrachtung der übergreifenden Struktur der Anwendung,
Die Bewertung der Qualität und Benutzerfreundlichkeit un- sowie die Community waren nicht Teil des Projektauftrags.
terliegt im Bereich der Unterhaltung und Spiele anderen
Merkmale als beim klassischen Usability-Engineering für
92. VORGEHEN &
PROJEKTSETUP
1011
VORGEHEN & PROJEKTSETUP
2.1 Vorgehensmodell
Nach der Betrachtung verschiedener Vorgehensmodelle Alternative Modelle wie zum Beispiel Contextual Design von
fiel die Wahl auf ein benutzerzentriertes Vorgehen nach ISO Beyer und Holtzblatt oder das Double Diamond Modell des
9241-210 in Kombination mit Methoden aus ‘Goal-Directed British Design Council wurden nicht weiter betrachtet. Als
Design’ von Cooper (2014) und dem Google Design Sprint Begründung muss die zum Zeitpunkt der Evaluation unzurei-
nach Knapp (2017). Diese Kombination erlaubte es, auf die chend vorhandene Dokumentation und der Mangel an Erfah-
je nach Projektphase unterschiedlichen inhaltlichen Schwer- rung in der Anwendung der Modelle aufgeführt werden.
punkte mit passenden Methoden aus den gewählten Model-
len einzugehen. Begründung der Wahl
Anhand des Vergleichs der verschiedenen Modelle fiel die
Evaluation Wahl auf ein benutzerzentriertes Vorgehen nach ISO 9241-
Das eingesetzte Modell sollte ein benutzerzentriertes Vorge- 210, ergänzt mit Methoden aus ‘Goal-Directed Design’ von
hen methodisch unterstützen und Orientierung beim Projek- Cooper und dem Google Design Sprint nach Knapp. Da-
tablauf geben. Basierend auf der Fragestellung und einer frü- durch entstand eine Kombination aus klarem Prozessablauf,
hen Version der Risikoliste wurden folgende Anforderungen welcher den gezielten Aufbau von neuem Domänenwissen
für die Evaluation eines Vorgehensmodells formuliert: vorsah, und flexibler Methodenwahl pro Projektphase.
ƳƳ Iteratives Vorgehen bei der Erarbeitung von Designlösun-
gen inkl. Evaluation
ƳƳ Unterstützung bei der Einarbeitung in eine neue Domäne
(Gaming & Game Experience)
ƳƳ Flexible Methodenwahl
ƳƳ Einbezug des Auftraggebers in Konzeption & Design
Vergleich der Vorgehensmodelle
Name Nachteile
5S Modell Das Modell wurde primär für Projekte im Bereich von Websites entwickelt.
(Garrett, 2010)
ISO 9241-210 Offene Methodenwahl, einzelne Projektschritte sind wenig konkret formuliert
(2011)
Usability Engineering Lifecycle Aufbau und Ablauf des Modells sind für kleine Teams wenig flexibel, Erfahrung im Projektteam
(Mayhew, 1999) fehlen.
Goal-Directed Design Design wird als Expertentätigkeit ohne direkten Einbezug von Externen (z.B. Auftraggeber)
(Cooper, 2014) durchgeführt. Erstellung von Design-Lösungen und deren Evaluation mit Benutzern folgen spät im
Projektverlauf auf ausführliches Research & Modelling.
Lean-UX Research wird zugunsten des ‘making over analysis’-Prinzip zurückgestuft.
(Gothelf, 2013)
Google Design Sprint Kein Platz für die Erarbeitung von Grundlagen (Domänenwissen).
(Knapp, 2017)
12VORGEHEN & PROJEKTSETUP
2.2 Vorgehensmodell und Zuweisung der Methoden
Das übergeordnete Vorgehensmodell nach ISO 9241-210 Design & Evaluation
stellte den groben Raster für die Projektphasen ‘Planung’, Die bereits zu Beginn identifizierten Projektrisiken bezüglich
‘Analyse des Nutzungskontext’, ‘Spezifikation der Nurtungs- technischer Machbarkeit von Designlösungen/Prototypen
anfoderungen’, ‘Entwicklung von Gestaltungslösungen’ und im Umfeld von 3D Games und der Unsicherheit bezüglich
‘Evaluation. der Anwendbarkeit von bereits dem Team bekannten Evalua-
tions-Methoden führten zu folgenden Anforderungen an das
Planung Vorgehen:
Die ‘Planung’ als Projektphase stellt insofern einen Sonder- ƳƳ Es sollen drei bis vier Iterationen mit Einbezug des Auftrag-
fall dar, als die zugehörigen Tätigkeiten und Artefakte in Form gebers bei der Erarbeitung, Priorisierung und Umsetzung
eines proaktiven Projektmanagements über die ganze Länge von Designlösungen gefahren werden.
der Masterarbeit weitergeführt und optimiert wurden. ƳƳ Jede Design Iteration muss anschliessend evaluiert
werden.
Artefakte: Projektplan, Zeiterfassung, Risikoliste,
Projekt-Log inkl. Reflexion. Insbesondere die gleichwertige Einbindung der Stakeholder
bei der Erarbeitung und Bewertung von Design-Lösungen
Da das Vorgehen nach ISO eine flexible Zuweisung der ein- sprach für ein zeitlich komprimiertes Vorgehen anhand der
zelnen Methoden zulässt, wurden die weiteren Phasen an- Google Design Sprint Methode nach Knapp. Ein Vorgehen
hand ihrer inhaltlichen Schwerpunkte zu ‘Analyse & Spezifi- nach Copper anhand der Phasen ‘Design Framework’ und
kation’ und ‘Design & Evaluation’ gruppiert. ‘Design Refinement’ empfand das Projektteam zur Anwen-
dung als ungeeignet.
Analyse & Spezifikation
Hier kamen fokussiert Methoden aus dem Goal-Direc- Artefakte: Mid-Fi Prototype, Visual Design, Findingsliste
ted-Design von Cooper zum Einsatz. Dabei wurden die in den
Kapiteln ‘Research’, ‘Modeling’ und ‘Requirements Definition’
beschriebenen Aktivitäten angewandt. Der Vorteil lag darin,
dass mit einem Vorgehen nach Cooper eine umfangreiche
Analysephase einhergeht, welche die Einarbeitung in eine
für das Projektteam anhin unbekannte Domäne ermöglichen
sollte. Zusätzlich liefert Cooper mit den Personas ein umfang-
reich dokumentiertes Werkzeug, um Benutzer zu erfassen
und deren Bedürfnisse, Wünsche und Ziele zu modellieren.
Artefakte: Konkurrenzanalyse, Beobachtungen, Expert
Review, Hypothetische Personas, Interviews, Personas,
Szenarien, Analytics, Findingsliste, Research zu
Gaming & UX
13VORGEHEN & PROJEKTSETUP
2.3 Risikoanalyse
Die Zusammenarbeit mit dem Projektpartner barg bereits zu Technische Implementierung
Beginn mehrere Risiken, weshalb sich das Projektteam dazu Die Struckd-App basiert auf der Unity-Engine und bietet die
entschloss, eine detaillierte Risikoanalyse durchzuführen und Möglichkeit 3D-Spiele zu erstellen. Das Erstellen von Proto-
die einzelnen Risiken zu bewerten sowie über den Projektver- typen, welche das Spielerlebnis realistisch zu vermitteln ver-
lauf zu verfolgen. Dazu wurde eine Risikoliste (siehe Anhang suchen und nicht mit Unity umgesetzt werden, schätzte das
II) mitsamt einer Historie aufgesetzt, welche regelmässig in Projektteam als zu wenig zielführend ein. Deshalb war man
den Weekly-Calls neu bewertet wurden. Risiken mit hoher für die Umsetzung der Prototypen von Struckd abhängig. Die
Eintrittswahrscheinlichkeit oder einem hohen potenziellen Bereitschaft seitens Struckd war da, jedoch stellte sich der
Schaden wurden mit sofortigen Gegenmassnahmen adres- zeitliche Aufwand als grösser heraus als anfangs angenom-
siert. Stellvertretend soll hier auf die drei grössten Projektri- men. Um einem sich abzeichnenden Engpass bei der Evalua-
siken eingegangen werden: tion der Design Lösungen entgegenzuwirken, wurde für
die Usability Tests mit einer Kombination aus einem Mid-Fi
Zugang zur Zielgruppe Prototypen, erstellt durch das Projektteam mittels Protopie.
Auf bestehende Benutzer der Plattform konnte nicht zurück- io, und einem Unity-Prototypen gearbeitet, was sich rückbli-
gegriffen werden. Zum einen konzentrieren sich diese Benut- ckend sehr bewährt hat.
zer aktuell in Südamerika, zum anderen benötigen wir für die
Evaluierung des Onboarding unbelastete Benutzer, welche in Evaluationsmethoden im Gaming Umfeld
die Zielgruppe passen, aber Struckd noch nicht gekannt ha- Das Projektteam verfügte bei Beginn der Projektarbeit über
ben. Agenturen zur Rekrutierung von Testpersonen konnten keine Erfahrungen in der Planung und Durchführung von
uns bei dieser Aufgabenstellung ebenfalls nicht weiterhelfen spezialisierten Evaluationsmethoden im Gaming-Umfeld. Die
da sie keine Testpersonen unter 18 Jahren vermitteln. Des- dadurch entstandene Unsicherheit wurde als Projektrisiko
halb entschied sich das Projektteam dazu, für die Rekrutie- hoch eingestuft. Als Reaktion wurde frühzeitig umfangreiche
rung die Zusammenarbeit mit Jugend-Organisationen zu Recherchen in den Projektplan aufgenommen – mithin ein
suchen. Folgende Organisationen konnten als Partner ge- wesentlicher Grund dafür, ein Vorgehen nach Cooper auszu-
wonnen werden: die ‘Jugendarbeit Fällanden’ (www.vjaf.ch) wählen. Zusätzlich wurden die vorgesehenen Methoden je-
und der Verein ‘Robi-Spiel-Aktionen’ (www.robi-spiel-aktio- weils vor dem Einsatz in der Evaluation der Design Sprints in
nen.ch). kleiner angelegten User-Tests erprobt und reflektiert, um die
Methodenkompetenz der Projektgruppe zu festigen.
14VORGEHEN & PROJEKTSETUP
2.4 Organisation im Team
Um die Projektziele zu erreichen, erwies sich eine enge Zusammenarbeit im Pro-
jektteam und mit dem Auftraggeber als wichtiger Bestandteil. Um dies sicherzu-
stellen wurden folgende Punkte im Team vereinbart:
ƳƳ Zentrale Ablage für Task, Daten, Dokumente und Resultate (Notion, Google Drive)
ƳƳ Wöchentlicher, telefonischer Austausch über den Projektfortschritt (Skype)
ƳƳ Gemeinsamer Slack-Channel für asynchrone Kommunikation
ƳƳ Regelmässige Sitzungen mit Coach der HSR
ƳƳ Regelmässige Treffen mit den Auftraggebern
ƳƳ Fest definierte Arbeitstage (pro Woche 1-2 Tage)
Eine fixe Rollenaufteilung unter den Team-Mitgliedern wurde bewusst nicht ange-
strebt, doch kristallisierten sich inoffizielle Rollen anhand der persönlichen fachli-
chen Schwerpunkten und Interessen heraus. Während Marco eine führende Rolle
beim Research der Evaluationsmethoden einnahm, brachten Florian seine Erfah-
rung bei der Anwendung des Google Design Sprints und Sebastian beim Aufbau
des Analytics-Konzeptes für Struckd ein. Dennoch wurde kein Resultat oder Ar-
beitsschritt alleinig durch ein Team-Mitglied geleistet, sondern immer in der Ko-
operation des Teams.
15VORGEHEN & PROJEKTSETUP
2.5 Projektplan
Planung
Das Projekt wurde, orientiert am Projekt-Vorgehen, in ver-
schiedene Phasen unterteilt, um die Projektziele im vorgese-
henen Zeitraum und Zeit-Budget zu erreichen (siehe Anhang I). Analyse
Cooper
Phase I: Research (KW 24-32)
Die erste Phase hatte zum Ziel, einerseits Wissen im Be-
reich UX im Gaming-Bereich aufzubauen und andererseits,
Evaluation Anforderungen
den Projekt-Partner, dessen Produkt und die bestehende
User-Basis kennenzulernen.
Phase II: Modelling & Requirements Definition (KW 32-35)
In der zweiten Phase wurden die Resultate aus der Vorphase Knapp Design
verarbeitet (Modellierung von Personas, Erstellung von Sze-
narien) und das erlernte Wissen aus der Recherche in das
Vorgehen eingearbeitet. Kombination der Vorgehensmodelle ISO,
Cooper und Knapp. Quelle: Eigene Darstellung
Phase III: Design Sprints (KW 36-50)
Mittels insgesamt vier Design-Iterationen wurden neue Lö-
sungen für die Verbesserung der User-Experience erarbeitet
und getestet.
Modelling &
Research Requirements
Definition
16VORGEHEN & PROJEKTSETUP
Design
Sprints
Reflexion
Aufgrund der späten Zusage des Projektpartners Struckd
konnte das Projekt erst verzögert starten. Deshalb wurde
bereits ab Beginn ein Projektplan mit mehreren Phasen
und Milestones definiert, welcher sich am Vorgehen orien-
tiert . Gleichzeitig wurden die verfügbaren Ressourcen über
den Projektplan verteilt und regelmässig abgeglichen. Dies
ermöglichte dem Projektteam jederzeit den Fortschritt im
Vergleich zum Projektplan zu kontrollieren.
Die Kombination aus Cooper und Knapp als Vorgehens-
modell erwies sich als ideal. Cooper erwies sich als geeignete
Methode um den Kontext zu verstehen und die Anforderung
zu definieren. Es unterstützt mit der Methode des Literatur
Studiums explizit den Aufbau des fehlenden Domänenwis-
sens. Die Personas waren ein wertvolles Artefakt um die
Nutzerperspektive beim Auftraggeber zu verankern. Knapp’s
Design Sprints zeigten sich als hilfreich für den engen Ein-
bezug der Stakeholder und half im Projekt technisch mach-
bare Lösungen zu erzielen. Knapp’s Vorschlag, einen Sprint
innert fünf Tagen ‘en bloc’ zu bewältigen, erwies sich aber als
unrealistisch. Das Projektteam, wie auch der Auftraggeber,
konnten eine solche Verpflichtung nicht eingehen. Eine kom-
primierte Anwendung der Methode bestätigte sich als prak-
tikabel. Rückblickend zeigen sich aber auch Nachteile. Die
unabhängige Ausarbeitung der Prototypen führten zu einem
grösseren Abstimmungsaufwand zwischen Auftraggeber
und Projektteam.
17Quelle: Alessandro Fischer
183. RESEARCH
Eine wichtige Grundlage für erfolgreiches Design ist das Wissen
über den Kunden, die Benutzer und deren Umgebung. Da das Pro-
jektteam eine nicht alltägliche Anwendung (Game-Editor; Spie-
le-Plattform) und ebenso unbekannte Benutzer antraff, bestand ein
wichtiger Teil der Research-Phase darin, Wissen über den Kontext
und die Benutzer aufzubauen.
Cooper empfiehlt, zu Beginn des Projekts mittels eines Stake-
holder-Interviews zu starten. Dies verschafft einen Überblick über
den geschäftlichen und technischen Kontext. Parallel dazu soll das
Domänenwissen durch das Design Team mithilfe von Fachlitera-
tur aufgebaut und mit Selbstversuchen und Konkurrenzanalysen
vertieft werden. Der Schwerpunkt im Vorgehen nach Cooper liegt
jedoch auf den ethnografischen Interviews mit Benutzern. Diese
helfen, die Verhaltensmuster der tatsächlichen und potentiellen
Nutzern zu identifizieren.
19RESEARCH
3.1 Stakeholder Interview
Stakeholder Interviews dienen dazu, zentrale Informationen über das Busi-
ness-Modell, die Unternehmens-Ziele und -Vision, aber auch über die technischen
Rahmenbedingungen des Produkts zu sammeln. Dabei rät Cooper das Interview
vor dem User Research durchzuführen, weil die Erkenntnisse den Verlauf der Nut-
zerforschung beeinflussen können. Dabei wird empfohlen folgende Fragestellun-
gen zu beantworten: Vorläufige Produktvision, Budget, Zeitplan, technische Ein-
schränkungen, Geschäftsinteresse und User-Wahrnehmung der Stakeholder.
Der Start der Masterarbeit begann mit einem halbtägigen Meeting. Dabei zeigte
sich die Vision von Struckd, sich als Plattform für Spiele zu etablieren. «Unsere Vi-
sion ist es, dass Struckd, ähnlich wie Youtube für Videos, eine Plattform für Spiele
wird» (Flurin Jenal, 9. Juni 2017, Kick-Off Meeting). Als Differentiator zu ande-
ren Apps wartet Struckd mit einem 3D-Game-Editor auf. Diesem räumt Struckd
grosse Wichtigkeit ein, da dies die einzige Möglichkeit ist, um Content für die Platt-
form zu generieren.
Der Editor und die Spiele basieren auf der Unity-Engine, das Interface zur Aus-
wahl der Spiele auf Angular, welches in einer Webview ausgeführt wird. Mittelfris-
tig plant der Auftraggeber, den Editor zusätzlich via Desktop (Windows und OS X)
zur Verfügung zu stellen. Das Projektteam fokussierte sich für die vorliegende Un-
tersuchung auf die Mobile App.
Die Daten der Benutzer wie z.B. die Accounts, erstellte Spiele, gespielte
Spiele, Kommentare und Bewertungen werden in einer Datenbank auf einem Web-
server gespeichert und mittels Schnittstellen angeboten. Die App verfügt nicht
über einen Offline-Modus, welcher es erlaubt Spiele zu erstellen oder zu spielen
ohne konstante Internetverbindung. Zusätzlich steht Struckd via Facebook in en-
gem Austausch mit der Community. Diese Daten wurden bisher nie systematisch
erhoben oder analysiert. Folglich fehlte ein eindeutiges Bild der Zielgruppe und
deren Bedürfnisse. Die Hypothese des Auftraggebers lautete, dass eine Mehrheit
der Benutzer in der App Spiele spielen und eine Minderheit eigene Spiele kreiert.
Als Zielgruppe werden Kinder im Alter zwischen 8 und 14 Jahren definiert. Für das
Jahr 2018 steht die Monetarisierung der Plattform im Fokus. Diese soll durch zu-
sätzlichen Content wie zum Beispiel Assets oder vordefinierte Themes erreicht
werden. Detaillierte Pläne existieren aber zu diesem Zeitpunkt noch nicht.
Reflexion
Das Projektteam stellte nach dem Stakeholder-Interview fest, dass die aktuelle
Definition der Benutzer und deren Bedürfnisse stark auf unbestätigten Hypothesen
basieren. Dem aktuellen Erfolg mit über 30’000 Benutzern und über 10’000 erstell-
ten Spielen steht eine Retention-Rate von unter 1 % gegenüber. Dies bewegte das
Projektteam dazu, dem User-Research mehr Zeit als geplant einzuräumen. Für die
Umsetzung der komplexen Prototypen sicherte Struckd mehrere Monate Entwick-
lungsressourcen zu.
20RESEARCH
Quelle: Alessandro Fischer
3.2 Beobachtung
Beobachtungen eignen sich in einem frühen Stadium eines Die gesammelten Eindrücke aus der Beobachtung wurden
Projektes oder einer Studie, wenn das Wissen über ein System anschliessend im Team besprochen und in einer Findings-
oder über das Verhalten von Benutzern gesammelt wird. Es liste (siehe Anhang IV) dokumentiert. Zu den wichtigsten Er-
handelt sich dabei um ein eine pragmatische Methode, wel- kenntnissen gehören:
che sowohl hilft, das Domänenwissen innerhalb des Design- ƳƳ Die Teilnehmer zeigen grosse Begeisterung an der
Teams aufzubauen, als auch das Verhalten der Benutzer in Möglichkeit, ihr eigenes Spiel zu erstellen; sie sind in der
ihrer Umgebung zu erfassen. Dabei können Erkenntnisse Lage, nach einer persönlichen Einweisung innerhalb von
gesammelt werden, welche durch eine quantitative Analyse einer Stunde ein Spiel zu kreieren.
oder durch Interviews nicht zum Vorschein kommen. ƳƳ Die Teilnehmer – und ganz besonders die jüngeren unter
Das Projektteam entschied sich, als erste Methode der ihnen – verfügen über eine beachtliche Fantasie und
Research-Phase die Beobachtung (Pure Observation) nach möchten diese gerne umsetzen. Von einer Idee zu einem
Courage (2005) anzuwenden. Diese Form von Beobachtung spielbaren Spiel benötigen sie aber Unterstützung (Was ist
wird dazu eingesetzt den Kontext zu erfassen, um z.B. die das Spielziel? Wie kann ich das Spielziel beeinflussen/
zukünftigen Forschungsziele zu präzisieren. Das Sammeln steuern?).
von Erkenntnissen und Erfahrungen zu einem Produkt in
dessen Kontext steht dabei im Vordergrund – und nicht die Diese Resultate wurden als Grundlage für die Definition der
Evaluierung von Lösungen. Ebenso wird die Interaktion mit hypothetischen Personas weiterverwendet.
dem Benutzer bewusst nicht gesucht.
Reflexion
Struckd führte an den Informatiktagen (https://informatik- Die Veranstaltung war für das Projektteam eine ideale Gele-
tage.ch/about) mehrere Veranstaltungen durch. In diesen genheit mit Benutzern in Kontakt zu treten und erste Erfah-
wurde einem Publikum zwischen 10 bis 14 Jahren die Diszi- rungen zu sammeln. Gleichzeitig konnte beobachtet werden,
plin des Spiele-Entwicklers näher gebracht. wie der Auftraggeber seine Plattform gegenüber dem Zielpu-
Das Projektteam nahm an einer dieser Veranstaltungen blikum vorstellt und verkauft. Ein Höhepunkt der Beobach-
teil, mit der der Absicht zu beobachten wie Struckd ihre App tung war, dass alle Benutzer schnell mit der Plattform zurecht
präsentiert, wie die Zielgruppe mit der App interagiert, wie kamen und nach ca. 30 Minuten erste Spiele vorweisen konn-
sich ihre Motivation verhält und inwiefern sich diese zwischen ten. Im Gegensatz zu Benutzern, welche das Spiel alleine zum
den Bereichen Editor und Spiel unterscheiden. Als Vorbe- ersten mal spielen, wurden die Besucher dieser Veranstal-
reitung wurde ein grober Beobachtungsleitfaden definiert tung gezielt durch Struckd instruiert, weshalb die Resultate
(siehe Anhang III). der Beobachtungen mit Vorsicht zu geniessen sind.
Eine weitere spannende Erkenntnis, welche sich zu
einem späteren Zeitpunkt zusätzlich verifizieren liess, brachte
die Beobachtung, dass die Teilnehmer deutlich mehr Spass
und auch Erfolg bei der Erstellung der Spiele hatten, wenn sie
dies gemeinsam machten und sich gegenseitig unterstützt
und motiviert haben.
21RESEARCH
3.3 Aufbau Domänenwissen
Für den Aufbau und Vertiefung von domänenspezifischen Ähnlich argumentiert Lazzaro (Isbister, 2008). Sie sieht die
Wissen im Design Team schlägt Cooper das Studium einer primäre Absicht von Spielsoftware darin, den Spieler zu un-
möglichst breiten Auswahl an Fachliteratur vor. Dabei sol- terhalten. Produktivitätssoftware hingegen dient bei ihr als
len auch Dokumentation sowie Vision- und Strategie-Do- Werkzeug, um die Aufgaben eines Benutzers zu vereinfachen
kumente des Auftraggebers hinzugezogen werden, um ein und zu beschleunigen. Aus dieser Betrachtungsweise leitet
möglichst ganzheitliches Bild zu erlangen. Anlässlich dieser Lazzaro wiederum für die beiden Bereiche klar differenzierte
Arbeit wurde die Literatur-Recherche mit folgendem Fokus Erlebniszielsetzungen (Experience goals) ab und stellt sie wie
betrieben: ‘Herausarbeiten der Gemeinsamkeiten bzw. folgt gegenüber:
Unterschiede in der Definition und Evaluation von Benutze-
rerlebnissen im Umfeld von Games gegenüber klassischen UX goals: productivity PX goals: entertainment
HCID Methoden’
ƳƳ Task completion ƳƳ Entertainment
Die inhaltliche Recherche wurde mithilfe verschiedener On- ƳƳ Eliminate errors ƳƳ Fun to overcome obstacles
line-Quellen, wie zum Beispiel researchgate.net oder aca- ƳƳ External reward ƳƳ Intrinsic reward
demia.edu, welche wissenschaftliche Publikationen bereit- ƳƳ Outcome-based rewards ƳƳ Process is its own reward
stellen, geführt. Anschliessend an die Recherche wurden ƳƳ Intuitive ƳƳ New things to learn
ausgewählte Inhalte und Publikationen zusammengefasst, ƳƳ Reduce workload ƳƳ Increases workload
und hinsichtlich ihrer Relevanz und Anwendbarkeit im Rah- ƳƳ Assumes technology needs ƳƳ Assumes humans need
men der Arbeit diskutiert. to be humanized to be challenged
In der Auswertung der Recherche-Resultate liess sich
feststellen, dass die verwendeten Begriffe im wissenschaft-
Unterschiedliche Experience-Goals bei der User-Experience (UX) und
lichen Umfeld durchaus analog zu derjenigen in der Betrach- Player-Experience (PX). Quelle: Isbister, 2008
tung von Produktivitätssoftware aufgebaut sind. Dies über-
raschte wenig, da ein grosser Teil der Grundlagenforschung
von Experten aus dem Feld der Human-computer-interaction Beim Vergleich der Erlebnisziele wird klar, dass je nach Be-
(HCI) stammt. trachtungsschwerpunkt andere Evaluations-Methoden zur
Der Hauptunterschied zwischen den beiden Be- Anwendung gebracht werden müssen. Basierend auf einer
reichen liegt laut Bernhaupt (2015) darin, dass im Ga- Auswertung aktueller Literatur schlägt Chu (2011) eine Ma-
ming-Bereich die Messung von Variablen wie Spass, Im- trix zur Kombination verschiedener Messmethoden vor, um
mersion oder Flow einen viel grösseren Stellenwert haben. eine umfassende Messung des Spiel-Erlebnisses zu gewähr-
leisten.
Game Experience
Playability (HEP)
Motion Through
methods, (CSR,
Finger Pressure
EMG, EKG, HR)
Evaluation for
Physiological
Heuristic for
Heuristics
Reader
Game
EMG
GEQ
Face
Flow
General Research
{
Qualitative ● ● ● ● ● ●
Methods Quantitative ● ● ● ●
Instruments to
{
Verbal ● ● ●
measure Emotion Non-Verbal ● ● ● ● ●
Pleasurable Products
{
Empirical ● ● ● ●
Measurement Non-Empirical ● ● ● ● ●
Methoden-Übersicht zur Evaluierung der Player-Experience in Games. Quelle: Chu (2011)
22RESEARCH
Als passend für das weitere Vorgehen wurde das For- Wahl der Evaluationsmethoden
schungs-Modell nach Lennard Nacke (2009) eingestuft. Dies Angelehnt an Nacke wurden mehrere Evaluationsmethoden
aus zwei Gründen: im Detail betrachtet und wie folgt geplant:
1. Die von Nacke vorgeschlagene Betrachtung eines Spieles ƳƳ Für die Messung des Spiel-Erlebnisses: Beobachtungen
mithilfe der Begriffe ‘Playability’ und ‘Player Experience’ kombiniert mit einem durch die Testteilnehmer auszufül-
ist weitgehend kompatibel zum gewählten Vorgehensmo- lenden Fragebogen, dem von Nacke erwähnten Game
dell. Experience Questionnaires (GEQ) welcher von IJsselsteijn
2. Zur Beurteilung der Tauglichkeit eines Interfaces und der (2013) im Rahmen des internationalen Projekts ‘Fun of
umfassenden Messung eines Spiel-Erlebnisses wird eine Gaming’ (FUGA) erarbeitet wurde. Die Wahl dieses
kombinierte Anwendung mehrerer erprobter Evaluations- Fragebogens wurde durch eine bereits erhältliche
methoden, wie sie bereits bei Chu oder auch Bernhaupt deutsche Übersetzung beeinflusst.
erwähnt wurden, vorgeschlagen. ƳƳ Für die Evaluation der Playability: Einsatz einer passenden
Game-Heuristik als Teil der Expert Reviews und als
Framework für die Einteilung der Issues in der Findings-
liste. Dazu wurde das ‘Heuristic Framework’ nach Hoch-
Design leitner (2015). verwendet. Die Wahl dieser spezifische
Sammlung von Heuristiken wurde durch mehrere Faktoren
Playability begünstigt: dem Vorhandensein einer umfangreichen
Dokumentation, einer aktiven Autorenschaft welche
bereits die dritte Überarbeitung verfügbar gemacht hat,
und der Tatsache, dass das Anwendungsgebiet nicht auf
Player Game einen Gametyp limitiert ist.
Reflexion
Als herausfordernd bei der Recherche stellte sich sowohl die
Player Experience
schiere Menge der verfügbaren Publikationen als auch das
Fehlen eines oder mehrere in der Game-Szene akzeptierten
Die Schnittstellen zwischen Spieler, Spiel und Designer zeigen, dass die Standardwerke zum Thema benutzerzentriertes Vorgehen
Spielbarkeit durch das Design, das Erlebnis jedoch durch die Interak- dar. Zu mehreren Diskussionen führte im Projektteam auch
tion zwischen Spiel und Spieler beeinflusst wird. Quelle: Nacke (2009)
die Frage, welche Publikationen bereits als veraltet bzw. über-
holt eingeordnet werden müssen. Schlussendlich muss aber
Laut Nacke stellt eine hohe Playability eine Vorbedingung für vermerkt werden, dass die Literatur-Recherche zu einem
ein gutes Spiel-Erlebnis dar. So sollte ein Spieldesign keine Überblick über den aktuellen Stand der Erforschung des
Probleme enthalten, welche einem individuellen Spiel-Erleb- Benutzererlebnisses in Games geführt und damit einen ver-
nis im Weg stehen. Für die Evaluation der Playability schlägt tieften Einstieg in die Thematik ermöglicht hat.
Nacke insbesondere die Verwendung von Expert Reviews
mithilfe von game-spezifischen Heuristiken vor.
Bei der Bewertung der Player-Experience setzt Nacke
auf eine Kombination von unterschiedlichen biometrischen
Messmethoden wie Elektromyografie (EMG), Elektroen-
zephalografie (EEG) und Eye-Tracking, ergänzt mit einer post
ludum durchgeführten Selbsteinschätzung der Spieler mit
Hilfe des Game Experience Questionnaires (GEQ).
23RESEARCH
3.4 Selbstversuch mit Expert Review
Bei einer Heuristischen Evaluation handelt es sich um eine Im Laufe der Research Phase wurden durch das Projektteam
durch Experten durchgeführte Betrachtung eines Systems, insgesamt fünf Expert Reviews der bestehenden Plattform
in welcher überprüft wird, ob ein Interface konform zu durchgeführt. Drei Reviews bezogen sich auf den sogenann-
bestimmten anerkannten Prinzipien (Heuristiken) ist. Auch ten Struckd Editor, zwei auf ein Spiel welches auf der Start-
Cooper empfiehlt, vorhandene Versionen oder Prototypen seite der Struckd Applikation als ‘beliebt’ aufgeführt wurde.
des Produktes in Form eines Expert Reviews zu evaluieren.
Dies mit der Absicht, dass Team mit den Stärken und Schwä-
chen der aktuellen Software und deren generellem Funkti-
onsumfang bekannt zu machen.
Einschub: Heuristiken & Expert Review
Für die Durchführung der Expert Reviews wurden mehrere Begründung der Wahl
Heuristiken evaluiert. Dabei standen folgende Kriterien im Die Wahl fiel auf die Heuristiken von Hochleitner. Sie liefern
Vordergrund: mit ihrem gut dokumentierten Framework ein Set an insge-
ƳƳ Heuristik ist spezialisiert auf das Game-Umfeld samt 48 Heuristiken. Diese sind in zwei Abschnitte mit un-
ƳƳ Zeitgemässe Version vorhanden (Games haben sich in den terschiedlichen Schwerpunkten unterteilt. Während sich der
letzten 10 Jahren, seit Einführung des iPhone, deutlich Abschnitt ‘game play/game story’ mit Elementen der Player
entwickelt) Experience befasst, konzentriert sich ‘virtual interface’ auf
ƳƳ Beispiele zur Anwendung der Heuristiken vorhanden & die Nutzbarkeit des Interfaces.
Nachweis bezüglich ‘Wissenschaftlichkeit’ erbracht
In der engeren Auswahl standen folgende Heuristiken:
Nielsen (1995) Klassische Usability Heuristiken, ev. Hilfreich für das UI eines Spieles zu evaluieren, aber nicht
relevant um Probleme des Gameplays zu identifizieren.
Playability Heuristics for Mobile Games, Einfach zu verstehen aber relativ ‘alt’ (2006)
Korhonen (2006)
Evaluating Computer Game Usability: Fokus auf reine Usability.
Developing Heuristics Based on User Expe-
rience, Brown (2008)
User Experience Design for Inexperienced Set von Heuristiken mit dem Fokus auf ‘unerfahrene’ und ‘Neu-Spieler’
Gamers: GAP—Game Approachability Es wird ‘nur’ das Onboarding betrachtet.
Principles, Desurvire (2010)
A Heuristic Framework for Evaluating User Insgesamt 48 Heuristiken unterteilt in 2 Abschnitte ‘Game Play / Game Story’ und ‘Virtual Inter-
Experience in Games, Hochleitner (2015) face’ mit dem Schwerpunkt UX (Definition) und Usability. Die Heuristiken wurden seit 2009 zweimal
weiterentwickelt. Umfangreiche Dokumentation zur Anwendung im Rahmen eines Expert reviews
vorhanden.
24RESEARCH
3.5 Konkurrenz Analyse
Durchführung Expert Review Cooper empfiehlt eine Analyse der Hauptkonkurrenten, um
Die Expert Reviews wurden nach der bei Hochleitner doku- einerseits ein Gefühl über den Stand der Technik zu erhal-
mentierten Vorgehensweise durchgeführt: ten, und andererseits mögliche Fragen für die Interviews zu
1. Vor der Durchführung der eigentlichen Reviews arbeite- finden.
ten sich die Experten in den Aufbau der Heuristiken ein,
um ein gemeinsames Verständnis zu entwickeln. Gemäss Aussage des Auftraggebers ist Roblox die direkte
2. Die Experten evaluierten anschliessend spielend für 30 Konkurrenz. Weiter untersuchte das Projektteam Minecraft,
Minuten ausgewählte Bereiche der Struckd Applikation. ebenfalls ein sogenanntes Sandbox-Spiel mit internatio-
Probleme, welche während dem Spiel auftraten, wurden nalem Erfolg. Die Games wurden über einen Zeitraum von
als Notizen festgehalten. mehreren Wochen selbst regelmässig genutzt und analysiert
3. Die gefundenen Probleme wurden im Plenum den (siehe Anhang V). Bei seinem Research traf das Projektteam
passenden Heuristiken zugeteilt und mit einer Kennung auf weitere gleichartige Sandbox-Games, entschied sich
versehen in die Findingsliste übertragen. Anschliessend aber, keine weiteren Konkurrenz-Analysen vorzunehmen –
vergaben die Experten einzeln pro Problem ein Rating insbesondere deshalb, weil die geplanten Design Sprints
anhand der ‘severity scale’ von Nielsen (1995), welches mittels ‘Lightning Demos’ dies bereits zielgerichtet vorsahen.
abschliessend zu einem Konsens-Rating konsolidiert
wurde. Reflexion
Es bestätigte sich die Aussage von Cooper, dass sich durch
Reflexion die Methode Fragen für die Interviews finden lassen. Zusätz-
Beim Zeitpunkt der Evaluation einer geeigneten Heuristik war lich half die Konkurrenzanalyse das Profil für die Rekrutierung
aus Sicht des Projektteams noch nicht absehbar, welchen passender Kandidaten für den Nutzer-Research zu schärfen.
Einfluss die Auswahl auf den weiteren Projektverlauf haben
wird. Insbesondere die mit den gewählten Heuristiken einge-
hende umfassende Betrachtungsweise eines Spiels, unter-
teilt in Aspekte der Usability und der Player Experience, wel-
che aber nicht auf einen spezifischen Game-Typ beschränkte
war, stellte sich im Rückblick als eine gute Wahl heraus.
Die im Vergleich zu Sammlungen anderer Autoren grosse
Anzahl an einzelnen Heuristiken (48) brachte anfänglich aber
auch Probleme mit sich. Bei der erstmaligen Anwendung des
Frameworks war es dem Expertenteam nicht immer möglich,
auf Anhieb einen Konsens bei der Zuordnung der Probleme
zu den Heuristiken zu finden. Insgesamt führte dies zu einem
deutlich höheren Zeitaufwand als geplant.
Zusätzlich wurde für die bereits eröffnete Findingsliste
eine Überarbeitung anhand der Systematik des Heuris-
tik-Frameworks notwendig. Diese Überarbeitung ermög-
lichte es, die bestehenden und zukünftigen Findings anhand
der Heuristiken gezielt abzulegen, zu bewerten und für die
Spezifikations- und Designarbeiten weiterzuverwenden. Projektteam bei der Durchführung des Expert Reviews.
25RESEARCH
3.6 Analyse von Daten
Bei der Verwendung von analytischen, quantitativen Daten Da die Struckd-App seit mehreren Monaten online ist und
in der Research-Phase ist Vorsicht geboten, da Daten ledig- durch Benutzer aus aller Welt verwendet wird, haben sich
lich ein Verhaltensmuster darstellen, jedoch nicht klar statistische Daten angesammelt. Als eine ergänzende Quelle
den Handlungsgrund oder die Motivation dafür verraten. war es die Absicht des Projektteams, aus diesen Daten Er-
Dadurch müssen die Daten interpretiert werden und soll- kenntnisse für die Weiterentwicklung abzuleiten und in die
ten als Hypothese angesehen werden. Nach Cooper werden weitere Arbeit mit einzubeziehen. Ziel war es, die Daten einer-
analytische Daten dazu eingesetzt, Fragen aufzudecken und seits für die Generierung von neuen wie auch zur Validierung
nicht Antworten zu finden. Trotzdem bieten quantitative bestehender Erkenntnisse zu verwenden. Darüber hinaus
Daten die Möglichkeit, Hypothesen für nachfolgende quali- sollten die demografischen Daten die Anreicherung der Per-
tative Untersuchungen zu bilden oder qualitativ erarbeitete sonas unterstützen.
Resultate zusätzlich zu untermauern. Gerade in unserer Seitens Struckd wurde bis zum aktuellen Zeitpunkt kein
Zeit, in welcher digitale Services für eine sehr grosse Nutzer- Konzept für die Sammlung von statistischen Daten verfolgt,
gruppe bereitgestellt werden, entspricht eine systematische, weshalb keine Metriken und Informationen systematisch ge-
quantitative Messung der User-Experience einem grossen sammelt wurden. Jene, die gesammelt werden, verteilen sich
Bedürfnis. über mehrere Datenquellen:
Bei der quantitativen Erhebung macht es Sinn, von Ana- Appstores
lytics-Frameworks mit ihrer Empfehlung für Vorgehen, Me- (iOS Appstore, Google Playstore): Zahlen über getätigte
triken und Tooling zu profitieren. Ein Framework, welches Downloads und Updates der Apps.
sich im Zusammenhang mit der Messung der User-Experi-
ence anbietet, ist das HEART-Framework von Kerry Rodden, Unity-Statistic
Hillary Hutchinson und Xin Fu (Rodden, 2010). Es beinhal- Identifikation der einzelnen User und ihre Aktivität. Aus die-
tet ein Vorgehen und eine Struktur, welche es ermöglichen, sen Daten wurde ebenfalls die Retention-Rate abgeleitet
eine Entscheidungsgrundlage für die Produktentwicklung zu (Standard-Metrik aus Unity-Statistic).
schaffen, die sowohl auf Daten wie auch auf der User-Expe-
rience basiert. Das Framework behandelt insgesamt die fünf MySQL-Datenbank
Metriken Happiness, Engagement, Adoption, Retention und Sämtliche Daten der App werden in Tabellen einer MyS-
Task Success: QL-Datenbank gespeichert. Dazu gehören die Benutzer, Ga-
ƳƳ Happiness repräsentiert den Wert über das Erlebnis der mes, Build-Sessions, Play-Sessions, Highscores, Kommen-
Benutzer und deren Zufriedenheit bei der Verwendung tare, Bewertungen, Packs (Themes), Channels.
der Applikation.
ƳƳ Engagement beschreibt die Häufigkeit und Intensität Facebook
von Engagement der Benutzer mit den Inhalten über einen Die Struckd-Community umfasst über 3’600 Mitgliedern. Ei-
bestimmten Zeitraum. ner zusätzlichen geschlossene Gruppe von 1’200 Mitgliedern
ƳƳ Adoption zeigt auf, wie attraktiv die Applikation für neue wird aktiv in die Weiterentwicklung involviert.
Benutzer ist und widerspiegelt hauptsächlich die Effizienz
der Werbemassnahmen. Mit folgenden Problemen war das Projektteam bei der Aus-
ƳƳ Retention gibt Auskunft über die Benutzer-Treue über wertung der Daten konfrontiert:
unterschiedliche Zeiträume. ƳƳ Die Datenquellen der MySQL-Datenbank und Unity-Stati-
ƳƳ Task Success repräsentiert klassische Messwerte stic lassen sich nicht verknüpfen, wodurch keine Rück-
wie z.B. die Effizienz und Effektivität. schlüsse über Verhalten der Benutzer und generierte
Daten gemacht werden können.
ƳƳ Es werden nur Daten in der MySQL-Datenbank abgespei-
chert, wenn ein Benutzer registriert ist (Publikation eines
Spieles, Speicherung eines Highscores). Da eine Regist-
26RESEARCH
Vergleich zwischen erstellten und gespielten Themes. Quelle: Eigene Darstellung.
rierung nur beim Publizieren eines Spieles zwingend ist, Resultate
sind die Daten unvollständig und nicht aussagekräftig. Dank der bestehenden Daten konnten einige wenige Infor-
ƳƳ Ein Benutzer kann nur in angemeldetem Zustand eindeutig mationen gewonnen werden, welche in die Modellierungs-
über mehrere Plattformen wiedererkannt werden. Dadurch und Design-Phase eingeflossen sind:
sind Metriken wie Retention, Adoption oder Engagement ƳƳ Die Retention-Rate über 30 Tage beläuft sich auf 0.8 % und
nicht durchgängig möglich. stellt gleichzeitig die wichtigste Kennzahl gegenüber den
ƳƳ Der Detaillierungsgrad der Aktivitäts-Erfassung innerhalb Investoren der Struckd AG dar.
der Plattform ist nicht ausreichend. Es werden nur ein ƳƳ Das Theme ‘Media Madness’ ist sowohl bei den gespielten
Bruchteil der möglichen Aktivitäten der Benutzer erfasst, Spiele wie auch bei den erstellten Spiele das beliebteste
wodurch kein vollständiges Bild erstellt werden kann. Theme.
ƳƳ Im Schnitt (Mittelwert) erstellt ein Benutzer 1 Spiel, 75 %
Die Schwierigkeit bei der Verwendung dieser Daten ist es, (Median 75) der Benutzer erstellen maximal zwei Spiele.
dass diese kaum oder nur mit immensem Aufwand und Un- Diese Zahlen zeigen auf, dass die Plattform über einen
schärfen miteinander verknüpft werden können, und nur iso- kleinen Kern verfügt, welcher einen Grossteil des Content
lierte Auswertungen vorgenommen werden können. Aussa- produziert, was nicht dem Konzept von Struckd entspricht.
gen werden jedoch erst dank der Verknüpfung für die weitere
Verwendung relevant. Aus diesem Grund wurden nur wenige Reflexion
Auswertungen in der Analyse-Phase vorgenommen und zu- Die analytischen Daten bergen ein grosses Potenzial, sofern
sätzliche zusammen mit dem Auftraggeber ein Basis-Tra- die Erhebung bereits im Vorfeld berücksichtigt und systema-
cking-Konzept (siehe Anhang VI) aufgegleist, um zukünftig tisch geplant wird. Dies war eine grosse Ernüchterung in der
Daten aus der quantitativen Erhebung als Entscheidungsun- Zusammenarbeit mit Struckd, da die Daten weder vollständig
terstützung beizuziehen. noch die Datenquellen miteinander verknüpft waren. Aus die-
sem Grund war der Aufwand für die Auswertung der Daten
im Verhältnis zu den gewonnenen Erkenntnissen zu hoch.
Trotzdem wird der eingesetzte Effort als gewinnbringend
angesehen, da durch das Projekt nun ein Tracking-Konzept
für die zukünftige Messung entstand. Dieses muss durch
Struckd weiter verfeinert und mit Metriken ergänzt werden.
Dabei wird seitens des Projektteams empfohlen, sich an
das HEART-Framework zu halten, um betreffend Vorgehen,
Struktur und Tooling eine Vorgabe zu haben.
27RESEARCH
3.7 Nutzer-Interviews
Bei den ethnografischen Interviews nach Cooper wird sowohl 3.7.1. Persona Hypothese
mit aktuellen als auch potentiellen Benutzern gesprochen. Mit den bereits aus den durch Stakeholder Interview, Beob-
Ziel ist es, mit dieser qualitativen Methode Einblick in die achtung und Expert Review gewonnen Einsichten wird
unterschiedlichen Verhaltensweisen der Benutzer zu erhal- gemäss Cooper eine Persona Hypothese entwickelt. Diese
ten. Die Technik basiert auf der Grundlage eines Contextual dient als Ausgangspunkt für die weitere Rekrutierung und
Inquiry nach Beyer und Holtzblatt (Beyer, 1997). Cooper Planung der Interviews. Die Persona Hypothese sollte primär
weicht leicht von der theoretischen Grundlage des CI’s ab. auf wahrscheinliche Verhaltensmuster fokussieren und nicht
Das Gespräch wird auf maximal eine Stunde angelegt und auf demografische Attribute. Um deren Validität zu prüfen,
in kleinen, gleichbleibenden Teams durchgeführt. Damit ein wurden diese in einem zweiten Schritt mittels Interviews mit
effizientes Analysieren und Synthetisieren der Interview-Da- Vertreter aus der Zielgruppe überprüft.
ten möglich wird, sollte nach Cooper das gesamte Team mit
Usern interagieren. Anhand eines Affinity Diagrams nach Courage (2005) wer-
tete das Projektteam alle bisherigen Findings aus. Als Quel-
Mittels Personas möchte das Projektteam zusammen mit len wurden das Stakeholder-Interview, die Beobachtung an
dem Auftraggeber ein einheitliches Bild der Benutzer erlan- den Informatiktagen, der Selbstversuch, die Userdaten und
gen. Dabei sollen nicht nur demografische Daten, sondern die Ausprägungen der Heuristiken beigezogen. Dabei wur-
vor allem Aussagen über die Motivation und das Verhalten den zwei unterschiedliche hypothetische Personas entwi-
der Benutzer gemacht werden. Der Zugang zu bestehenden ckelt. Diese spiegeln auch die ursprüngliche Hypothese des
Benutzern konnte weder von Struckd noch vom Projektteam Auftraggebers wieder.
hergestellt werden. In Anbetracht dessen wurden potentielle 1. ‘Kevin’ als Ersteller von Spielen (Creator), mit dem
Nutzer mit ähnlichen Interessen rekrutiert. persönlichen Ziel Anerkennung aus der Community zu
erhalten.
2. ‘Sandro’ (Player) schätzt die Spiel-Vielfalt der Plattform,
und konzentriert sich auf das Konsumieren der Spiele.
Für ihn steht die Abwechslung und Vielfalt der Plattform
im Vordergrund.
Reflexion
In der verwendeten Literatur fehlte ein formaler Prozess zur
Identifikation der Verhaltensvariablen. Diese fehlende Grund-
lage führte zu Unsicherheit in der Definition der Variablen
und der Erstellung der Hypothesen. Bei der Reflexion dieses
Arbeitsschrittes kam der Verdacht
auf, dass mit den erstellten hypo-
thetischen Personas in erster Linie
die Wünsche und Lösungsansätze
des Projektteams und Auftragge-
ber projiziert wurden.
Skizzen der Persona Hypothesen.
28Sie können auch lesen
