Software Gameplay

Spiele machen Spaß und begeistern die Nutzer. Da könnte man in der Entwicklung „normaler“ Software schon einmal in die Versuchung kommen sich was davon abzuschauen.

Software muss aber nicht Spaß machen, wie ein Spiel Spaß machen soll. Software darf im Normalfall schon gar nicht kurzweilig sein, wie so das ein oder andere Spiel und muss auch in Stresssituationen einsetzbar sein.

Einiges im Aufbau von erfolgreichen Spielen kann jedoch durchaus auf die Erstellung von Software übernommen werden, denn Spiele besitzen u.a. folgende Eigenschaften:

• Regeln
• Ziele
• Feedback
• Wettbewerb
• Soziale Komponente
• Story und Emotion

Regeln

Die Stärke von Spielen ist, dass Sie ein klares Regelwerk haben. Manche ein sehr einfaches, manche ein äußerst kompliziertes, aber immer ein definiertes. Wer anders spielt kann dies tun, aber das ist dann ein anderes Spiel.

Kennen die Nutzer Ihrer Software die grundlegenden Regeln, die beachtet werden müssen?

Ziele

Spiele haben immer Ziele, die erreicht werden müssen. Bei Zielerreichung stellt sich eine Zufriedenheit ein. Gute Spiele zeichnen sich dadurch aus, dass am Anfang Ziele gesetzt werden, die durch jeden erreicht werden können und dann sukzessive immer schwieriger werden.

Fällt da schon der erste Unterschied zu Software auf? Zwar wird oft zwischen Anfängern und Fortgeschrittenen unterschieden, aber kann sich der Nutzer wirklich kontinuierlich an schwierigeren Aufgaben versuchen?

Feedback

Spiele geben dem Nutzer immer ein grausam ehrliches Feedback. You won! You loose! Game Over!

Software gibt natürlich auch ein Feedback, aber meist so: „Es ist ein Fehler aufgetreten – die Eingabe X im Feld Y ist unter der Bedingung Z nicht möglich.“.

Besser als nichts, aber der Nutzer würde sich auch einmal über ein positives Feedback freuen und immer über ein Feedback, welches mit einem Ziel zusammenhängt, was er gerade versucht zu erreichen. Das ist für die meiste Software aber gar nicht machbar, da ja gar keine solchen Ziele dem Nutzer als Aufgabe gestellt werden.

Wettbewerb

Spiele sind immer ein Wettbewerb. Man spielt im Multi-Player-Modus oder zumindest gegen Computer. Und selbst wenn man wirklich alleine spielt, spielt man gegen die Highscore-Liste mit alten Versuchen.

Dies ist in normaler Software schwierig umzusetzen ohne albern zu wirken. Das beste Instrument sind natürlich Metriken. Man stelle sich z.B. eine Bugtracking Software vor, die den besten Tester (= Fehlereinträge mit wenigsten Rückfragen und wenigsten falschen Einträgen) in einer Statistik für alle sichtbar führt.

Soziale Komponente

Spiele sind oft besonders erfolgreich, wenn diese zusammen mit anderen Menschen gespielt werden können.

Auf Software gemünzt heißt das: Macht die Menschen hinter den Daten sichtbar. Man muss ja gar nicht mit „Sozialen und vernetzten Anwendungen“ starten. Es würde ja oft schon einmal reichen, wenn ein Ticket-Ersteller wüsste, wie sein Bearbeiter heißt. Und noch schöner wäre es natürlich zu wissen, wie dieser Bearbeiter auch aussieht.

Selbst wenn jemand sagt „sieht aus wie eine eingebildete Zicke“ ist das noch um Längen menschlicher und damit besser als die Empfindung „wieder so ein Roboter“.

Story & Emotion

Das Unerklärlichste an Spielen aus Sicht eines Softwareproduzenten ist, dass Menschen freiwillig ihre Zeit dazu verwenden und dabei noch Spaß haben.

Die wichtigste Komponente ist oft eine Story, bei der man dranbleibt und auf keinen Fall die Fortsetzung verpassen will.

Dies ist definitiv nicht für jede Software umsetzbar und wäre für eine Automatisierungssoftware die 100x pro Tag pro User verwendet wird wenig sinnvoll.

Aber der Anteil der Projektorientierten Arbeit scheint stetig zu steigen (in Deutschland so 30%). Machen wir aus dem Projekt doch eine Story!

Fazit

Unter dem Ansatz Software mit einem Spielcharakter zu versehen ohne ernsthafte Software zu Ulk-Veranstaltungen degenerieren zu lassen, kann man viel Verbesserungspotential in der User Experience entdecken.

Jeder Software-Analyst, Designer und Programmierer sollte sich aus meiner Sicht Gedanken machen, wie er Regeln, Ziele und Feedback für seinen Problembereich adaptieren kann.

Man muss sich Gedanken machen, wie man diese Regeln und Ziele in seine Software einbaut, ohne dass der Nutzer es bewusst mitbekommt, dass ihm jetzt die Regeln erklärt werden und dass er jetzt eine Aufgabe gestellt bekommt, die er lösen muss.

Wenn man diese Basics umgesetzt hat, kann man in einem nächsten Schritt bewerten, was Wettbewerb, Soziale Komponenten, Story und Emotion in der eigenen Software bewirken können.