|
|||||||||||||||||||||||||||||
playability #1 [juli 2003] Marc Hassenzahl: Spielend arbeiten? Computerspiele und 'ernsthafte' Software Ernsthafte' Software (z.B. eine Textverarbeitung) und Computerspiele werden nur selten als vergleichbare Produkte verstanden. Zu tief scheint die Kluft zwischen Arbeit und Spiel. Dabei haben Spiele und ernsthafte Software einige Gemeinsamkeiten. Bei beiden spielt das Erreichen von Zielen – seien es nun Arbeitsziele oder Fantasieziele – eine entscheidende Rolle. Zielerreichung benötigt zwei Qualitäten: Barrierefreiheit (usability) und Motivation. Der vorliegende Artikel will Gestalter ernsthafter Software dazu anregen, von Spielegestaltern zu lernen, wie man Benutzer richtig motiviert. Andersherum können Spielegestalter lernen, wie mit einem "spieler-zentrierten" Gestaltungsprozess das Risiko "am Spieler vorbei zu gestalten" minimiert werden kann.
Die meisten Menschen sehen eine deutlichen Unterschied zwischen Arbeit und Spiel. Als dementsprechend verschieden werden "ernsthafte" Software (z.B. Textverarbeitung, Buchhaltungssoftware etc.) und Computerspiele wahrgenommen. Würde man die Produktmanagerin des neuesten Personalwirtschaftsmoduls von SAP bitten, ihr Produkt mit einem Computerspiel zu vergleichen, würde sie ob des frivolen Vergleichs wahrscheinlich Befremden zeigen oder sogar Ärger. "Spielzeug" scheint nicht nur ein unpassender Ausdruck für eine solches Softwareprodukt; er ist sogar noch negativ konnotiert. Spielzeuge sind wertloses Zeug. Nur Amateure benutzen Spielzeug. Dabei sind die Unterschiede zwischen ernsthafter Software und Spielen aus psychologischer Sicht nicht besonders groß. Mit ernsthafter Software erreicht man Ziele (z.B. einen Brief an einen wichtigen Kunden) durch das Erledigen einer Reihe von Aufgaben (z.B., schreiben, formatieren, überarbeiten, ausdrucken). Bei Spielen findet sich eine identische Struktur. Der Spieler hat meist eine zentrales Ziel (z.B. die Welt retten), das durch das Erledigen einer Reihe von Aufgaben (z.B. einen Geheimbund aufspüren, dessen Chef zur Strecke bringen) erreicht werden kann. Grob vereinfacht spielt beim Gebrauch einer Software – egal ob ernsthaft oder spielerisch – Zielerreichung eine zentrale Rolle.
Auf den zweiten Blick: Ernsthafte Software versus Spiele Zielerreichung muss zunächst prinzipiell möglich sein. Das setzt voraus, dass das Softwareprodukt die notwendigen Funktionen hat und diese auch vom Benutzer verstanden werden. Habe ich das Ziel, einen Brief zu schreiben, muss mir also ein Softwareprodukt zunächst die Möglichkeit geben, einen Brief zu schreiben. Ist das gegeben, muss man als Benutzer auch noch in der Lage sein, die zum Ziel gehörenden Aufgaben zu erledigen. Diese beiden Aspekte - Nützlichkeit und Benutzbarkeit - stellen heutzutage einen wichtigen Bestandteil der Produktqualität dar: die Gebrauchstauglichkeit oder auf Neudeutsch usability. Usability ist auch bei Spielen ein wichtiger
Aspekt. Im Rahmend der Bewertung durch die Fachpresse spiegelt sich
das in Kriterien wie "Bedienung" (GameStar) oder "Steuerung" (PC Games) wieder. "Zu hoher Schwierigkeitsgrad",
"umständliche Steuerung", "schlechte Sicht durch
ungünstige Kameraführung" oder "eingeschränkte
Speichermöglichkeiten" sind typische usability-Probleme in Spielen (siehe auch Tabelle
1). Diese Probleme erscheinen oft klein, können aber dazu führen,
dass ein Spieler die Lust am Spiel verliert. Oder es kommt zu einer
expliziten Abwertung des Spiels, wie bei Indiana Jones 6, dem die Spieletester des GameStar eine höhere Bewertung als 80% wegen
der unzureichenden Speicherfunktion verweigerten.
Tabelle
1: Typische usability-Probleme in aktuellen Spielen
Usability-Probleme stellen also ungewollte Barrieren beim Spielen oder allgemein beim Benutzen einer Software dar. Sie stören, tragen nichts zum Spiel bei - kurz: sie sind eine Belastung für den Spieler. Neben dem Vermeiden von Barrieren ist die Motivation weiter zu spielen die zweite wichtige Komponente zur Zielerreichung. Hier scheinen sich ernsthafte Software und Spiele deutlich zu unterscheiden. Die Ziele, für die man ernsthafte Software verwendet, können ein hohes Maß an Relevanz für den Benutzer haben. Der Bericht an den Vorstand, der unbedingt noch heute Abend abgeschickt werden muss, die neuesten Umsatzzahlen, die die Chefin für heute angefordert hat oder die dringende Online-Banküberweisung. Hier muss die verwendete Software sicher nicht mehr motivieren. Die drohenden Konsequenzen motivieren genug. Bei Spielen sind die Ziele nur selten so persönlich relevant. (Höchstens vielleicht, man spielt Counterstrike und hat sich vorgenommen mit seinem vom Hardwarehersteller gesponserten Clan die 15.000 Euro Preisgeld für den ersten Platz bei der ESL Pro einzuheimsen). Aus diesem Grund müssen Spiele wahre Motivationskünstler sein. Sie müssen interessante Ziele und spannende Wege zu diesen Ziele bieten, während ernsthafte Software immer den Vorteil hat, bereits vorhandenen Ziele abzudecken. Bei ernsthafter Software liegt der Nutzen also auf der Hand. Die Motivation kommt von "außen". Im wirklichen Leben stellt sich das etwas anders dar. Nur ganz wenig Ziele sind aus sich heraus motivierend und es ist oft schwer, die Motivation zur Aufgabenbearbeitung trotz Druck und drohender Konsequenzen aufrecht zu erhalten. Jeder kennt das Phänomen: "Bummeln" trotz nahender Prüfung oder das Verschieben unangenehmer Aufgaben trotz möglichem Ärger mit dem Chef. Motivierende ernsthafte Software könnte hier sicher wenigstens ein bisschen helfen. Es findet sich sogar ein wissenschaftlicher Beleg für diese These. Bei einer Untersuchung haben Igbaria, Schiffman und Wieckowski (1994) festgestellt, dass Mitarbeiter, denen der Umgang mit der Arbeitssoftware Spaß macht, häufiger und länger damit arbeiten (unabhängig von den Aufgaben, die sie erledigen müssen). Also selbst in einem vermeintlich unflexiblen Kontext, haben Arbeitende, die nicht motiviert sind mit einer Software zu arbeiten, offensichtlich die Möglichkeit, nur wirklich das Nötigste damit zu machen. Um es kurz zusammenzufassen: Sowohl bei ernsthafter Software als auch bei Spielen geht es darum Ziele zu erreichen und Aufgaben zu erfüllen. Dazu ist es notwenig, dass die Ziele eine gewisse Relevanz haben, keine Barrieren bestehen (d.h., usability-Probleme) und der Weg zum Ziel so gestaltet ist, dass Benutzer immer weiter motiviert werden, die nötigen Aufgaben wirklich auszuführen. Hier sind Spiele besonders interessante Modelle für Gestalter ernsthafter Software, denn Spiele haben eben nicht den unmittelbaren Nutzen, den jede ernsthafte Software mitbringt (vgl. auch Hassenzahl 2003).
Wie motiviert ein Spiel? Die Frage, die sich nun anschließt, ist: Wie motivieren Spiele eigentlich? Einen wichtigen Vorteil, den Spieleentwickler gegenüber Entwicklern ernsthafter Software haben, ist ihr breiterer Begriff von "Nutzen". Nutzen wird bei ernsthafter Software zunächst rein über die Funktionalität definiert. Ein Computertomograph beispielsweise macht es möglich, in den Körper, die Organe, die Knochen, den Schädel eines Menschen zu schauen. Das ist ein Nutzen. Der Nutzen kann gesteigert werden, wenn das Gerät und seine Bedienung effektiver, effizienter und sicherer (z.B. schneller, weniger Fehler) gemacht wird. Aber immer bleibt der Nutzen im Sinne eines klar definierten Ziels (z.B. Bilder vom Körperinneren machen) im Vordergrund. Der Nutzen
von Spielen ist diffuser. Primär geht es um Spaß, allerdings
kann Spaß sehr unterschiedliche Quellen haben. Garneau (2001)
kommt beispielsweise auf 14 verschiedenen Quellen (oder Formen)
von Spaß (siehe Kasten 1).
Kasten 1 Mein Kollege
Mark Blythe und ich (Blythe & Hassenzahl 2003) haben eine etwas
andere Einteilung von vergnüglichen Erlebnissen. Wir unterscheiden
Freude, ein auf Absorption beruhendes Gefühl, von Spaß,
einem Gefühl das hauptsachlich auf Ablenkung beruht (siehe
Kasten 2)
Kasten 2: Freude vs. Spaß (Blythe & Hassenzahl 2003) Eines macht Garneaus und unsere Liste deutlich: Spiele sprechen grundlegende menschliche Bedürfnisse direkt an, während ernsthafte Software, oder weiter gefasst, Arbeitskontexte, diese Bedürfnisse oft sogar verneinen. Kommunikationssysteme wie Email waren beispielsweise in Organisationen gerade zu Beginn ihrer Entwicklung verpönt, weil Sie über die eigentliche Arbeit hinaus zur sozialen Interaktion genutzt werden können. Dabei ist es für manche gerade die soziale Interaktion, die die tägliche Routine am Arbeitsplatz erträglich macht. Spielegestalter dürfen ihre Benutzer also ganzheitlicher sehen und mit ihren Spielen oft zentrale menschliche Bedürfnisse ansprechen, die Entwickler ernsthafter Software verneinen müssen. Denn oft herrscht die Meinung vor, dass Arbeit keinen Spaß machen darf. Wie erreichen es nun Spielegestalter, dass Spieler Stunden um Stunden mit einem Spiel verbringen? Zunächst erschaffen sie Mikrowelten, die den Spielern die Befriedigung eines oder einer ganzen Reihe der oben genannten Bedürfnisse ermöglichen. Außerdem werden noch drei elementare Aspekte beim Gestalten der Mikrowelt berücksichtigt (für eine ausführlichere Diskussion siehe Hassenzahl 2003):
Es ist nicht alles Gold, was glänzt: mehr Systematik in der Spieleentwicklung Ich verstehe also Spiele als Modelle und Quelle für Ideen zur Gestaltung attraktiver Software. Das heißt aber nicht, dass Spielegestalter nicht auch etwas von den Gestaltern ernsthafter Software lernen können. Softwareproduktion ist immer ein Risiko, das es zu minimieren gilt. Eine Möglichkeit das Risiko eines Flops zu reduzieren, ist die im industriellen Kontext immer häufiger angewendete "benutzerzentrierte Softwareentwicklung" (siehe beispielsweise Burmester & Hassenzahl 2000). Dabei ist man in allen Phasen der Entwicklung um ein möglichst objektives Urteil zur momentanen Qualität des Produkts aus Benutzersicht bemüht. Um die Objektivität zu sichern, werden Methoden angewendet, die aus der experimentellen Psychologie oder den Sozialwissenschaften stammen. Der benutzerzentrierte Gestaltungsprozess hat drei Merkmale. Er ist iterativ, empirisch und sozial. Ein von vorne herein iterativ (d.h. wiederholend) angelegter Prozess ist fehlertolerant. Es ergibt sich wiederholt die Möglichkeit, "Gestaltungsfehler" und dadurch entstehende Probleme zu entdecken. Ein empirischer (d.h. sich der Erfahrung aussetzender) Prozess ist risikominimierend, weil er Gestaltungsideen gemeinsam mit Benutzern entwickelt oder frühzeitig - also bevor viele Ressourcen in die Ausgestaltung der Idee geflossen sind - überprüft. Ein sozialer Prozess ist konfliktminimierend. Spiele werden im Team entwickelt. Die objektiv erhobenen Daten helfen dabei, Entscheidungen auf einer rationalen Basis zu treffen. Statt sich an nicht überprüfbaren Meinungen abzuarbeiten, was unweigerlich zu Konflikten führt, kann im Gestaltungsprozess auf der Basis objektiver Daten entschieden werden. Ein Beispiel für eine typische Methode der benutzerzentrierten Produktentwicklung ist der sogenannte usability-Test. Dabei werden Benutzer beim Umgang mit dem Produkt beobachtet. Zusätzlich müssen die Teilnehmer "laut denken", d.h. ihre momentanen Ziele verbalisieren. Verhalten sich die Benutzer anders als erwartet bzw. vom Gestalter vorgesehen, ist das ein sogenanntes "kritisches Ereignis". Kritische Ereignisse weisen auf zugrunde liegende usability-Probleme hin. Benutzer müssen sich gar nicht bewusst sein, dass gerade etwas schief läuft. Kritische Ereignisse sind Daten, die unabhängig von den Geschmäckern und Meinungen der Benutzer - kurz: objektiv - sind. Auf sie stützt der usability-Experte seine Diagnose und erarbeitet gemeinsam mit den Spielegestaltern entsprechende Gestaltungsvorschläge. Sicher werden Spiele getestet, bevor sie veröffentlicht werden. Aber meistens von Spielegestaltern selbst (die natürlich wissen wie ihr Spiel zu verstehen und zu bedienen ist) oder von "Hardcore"-Spielern, die schon alleine durch ihre Erfahrung nicht mehr als Testperson geeignet sind. So erklärt es sich vielleicht auch, dass der "überzogene Schwierigkeitsgrad" eine der häufigsten Kritiken in der Fachpresse ist. Einige der großen Spieleproduzenten leisten sich Experten, die Spiele vor Veröffentlichung ausgiebig wie oben beschrieben testen (z.B. Microsoft Game Studio). Diese Experten identifizieren dann empirisch usability-Probleme und suchen gemeinsam mit den Gestaltern Lösungen, die die Erfahrungen, Fertigkeiten und Fähigkeiten der Spieler berücksichtigen (siehe Pagulayan et al. 2003). Viele andere Spielegestalter haben den Wert einer solchen systematischen, methodengestützen "spieler-zentrierten Entwicklung" noch nicht realisiert. Sie gestalten oft noch für sich selbst, getreu dem Motto: wenn es mir gefällt, dann gefällt es auch den Anderen. Das mag in einer kleinern Gemeinschaft noch funktionieren. Mit der zunehmenden Verbreitung von Spielen, steigenden Kosten und steigenden benötigten Verkaufszahlen wird die Spieleproduktion jedoch zu einem schwer kalkulierbaren Risiko.
Schlussfolgerung Spiele und ernsthafte Software haben Vieles gemeinsam. Erfolgreiche Spiele können als Modell für attraktive Software dienen, denn sie machen Spaß und schaffen es Benutzer stundenlang zu motivieren. Und dies sind Qualitäten, die man sich auch für ernsthafte Software wünscht. Spiele können also eine Quelle für Gestaltungsideen sein. (So kann man beispielsweise durch Echtzeitstragiespiele wie StarCraft interessante Gestaltungshinweise für die Benutzungsoberflächen komplexer Energieverteilungsanlagen erhalten, siehe Weisscher 2001). Allerdings ist nicht jedes Spiel ein Erfolg. Spielegestalter müssen sich Methoden der "benutzer-zentrierten Softwareentwicklung" erschließen, um frühzeitig Gestaltungsideen zu generieren und zu bewerten. Nur so kann das zunehmende Risiko, das der Spieleentwicklung wie jeder anderen größeren Produktenwicklung innewohnt, minimiert werden.
Literatur Blythe,M. & Hassenzahl,M. (2003). The semantics of fun: Differntiating enjoyable experiences. In M. Blythe, C. Overbeeke, A. F. Monk & P. C. Wright (Hrsg.), Funology: From Usability to Enjoyment, S. 31-42. Dordrecht: Kluwer. Burmester,M. & Hassenzahl,M. (2000). Benutzerzentrierte Softwaregestaltung. Ergo-Online, http://www.sozialnetz-hessen.de/ergo-online/Software/S_Benutzer-SW-Gest.htm. Garneau,P.-A. (2001). Forteen forms of fun. Gamasutra, http://www.gamasutra.com/features/20011012/garneau_01.htm. Hassenzahl,M. (im Druck). Attraktive Software - Was Gestalter von Computerspielen lernen können. In J. Machate & M. Burmester (Hrsg.), User Interface Tuning. Benutzungsschnittstellen menschlich gestalten. Software & Support Verlag. Igbaria,M., Schiffman,S.J. & Wieckowski,T.J. (1994). The respective roles of perceived usefulness and perceived fun in the acceptance of microcomputer technology. Behaviour & Information Technology, 13[6], S. 349-361. Pagulayan,R.J., Steury,K.R., Fulton,B. & Romero,R.L. (2003). Designing for fun: User-testing case studies. In M. Blythe, C. Overbeeke, A. F. Monk & P. C. Wright (Hrsg.), Funology: From Usability to Enjoyment, S. 137-150. Dordrecht: Kluwer. Weisscher,A. (2001). Applying computer game techniques to process visualization. Information Design Journal, 10[1], S. 50-57.
|
