The game is the frame: what realworld software can learn from games

Sebastian Deterding has put together an attractive and substantive presentation for UXCamp Europe, exploring the principles of game design and how these principles may or may not be applicable to software design. Historically, user experience has focused on tasks and efficiency, not fun.

To cut to the chase, Deterding concludes that software user experience is fundamentally different from games, for two reasons. Most importantly, what makes games fun is that they are voluntary and have no real-world consequences. If there is obligation or consequences, then the fun goes away. Secondly, in a game, the designer controls the tools and the goals, but in realworld activities, the designer is traditionally very remote from the actual goals. At work, the goals are set by managers, by the needs of the company for things like sales and solving customer problems – not by the software designer.

To first order, Deterding is right, and this explains why the application of game design principles to realworld activities often falls short. Social software “game-design” systems that reward users for actions like making blog comments – actions that are meaningless by themselves, and become drudgery in a realworld context.

But I don’t think game principles apply only when there are no realworld consequences or obligations. For example, fundraising campaigns have long used public thermometers and social competition, for the realworld goal of supporting nonprofit causes. People participate in these programs as volunteers – it’s not the same kind of obligation as a job you’ll be fired from if you neglect. But people participate with a sense of community obligation, and the campaigns build on people’s sense of social obligation to each other. In a particular community, someone can choose not to participate, at some real cost to community standing.

To give another example, Chris Messina gave a recent talk, where he explains how he used game design practices from Flickr in helping to design and promote a campaign to spread Firefox, when the open source browser was a scrappy newcomer gaining recruits against incumbent Ineternet Explorer. The campaign had explicit tools that helped participants climb a ladder of activity, and meet their personal goals by meeting the goals of the Firefox project.

Ladder of participation, SpreadFirefox campaign

So I don’t think that a game needs to be free of realworld consequences or obligations. But the game needs to be aligned with those consequences and social dynamics.

The other issue that Deterding raises is that software designers are traditionally far removed from realworld goals. This is true – and this is something that needs to be fixed for game mechanics in realworld games to be anything more than window dressing. This means that tools need to be configurable to provide much more control to the people with real world goals, to integrate them into the experience.

Deterding reaches a similar conclusion to John Hagel, John Seely Brown, and their team at Deloitte, from a different direction. They argue that social software in the enterprise is bound to fail, unless and until it is connected to the realworld business goals and metrics. And this is going to be a key focus of the next generations of business social software.

Unlike Deterding, I don’t think that fun is orthogonal to realworld impact. But fun in a real world context is enabled (or, more often than not, removed) by social dynamics – by leadership and culture. And by the degree to which the goals of an organization align or thwart the goals of participants. Tools can’t do these things, can’t fix them if they’re broken, can’t add them if they’re missing.

So, I agree with Deterding that the shallow use of game dynamics doesn’t do much good for software for activities with realworld consequences. I am more optimistic than Detarding about the potential, but only when the goals and social dynamics, leadership and culture are aligned.

I strongly recommend the presentation if you are thinking about this topic – the presentation walks through elements such as clear goals, bite-sized actions, scaffolded challenges, and social comparison that make up a game, has good comparisons and contrasts with software design, and has good resources for further learning:

6 thoughts on “The game is the frame: what realworld software can learn from games”

  1. Dear Adina,

    thanks for the kind words and thoughtful reply. I fully agree with your point that fun is not orthogonal to real world outcomes or consequences (and now I fear that I came across more pessimistic and categorical than I intended to ^_^).

    I *do* think that the optimal structuring of activity with clear goals, scaffolded challenges, tasks chunked into a doable size, immediate feedback etc. can do much to improve the experience and motivational dynamics of any activity, online or off-. The Firefox campaign you mentioned is an excellent example of providing a scaffold to facilitate community participation (Nina Simon from Museum 2.0 has a wealth of insights on the importance of scaffolds for engagement).

    The point I was trying to articulate is that this works *not* primarily because points, badges etc. deliver some extrinsic reward for the activity – which is the common, rather behaviorist framing established by people like Byron Reeves (“Total Engagement”). Rather, this works because it helps to structure activity in a way that it becomes intrinsically motivating and a more “optimal” experience. Your thermometer is a good case in point – it gives an achievable goal, visual feedback on your current progress and actions. This is not a reward; what it does is to structure activity so that it better suits the way human motivation works.

    As for real-world consequences, again I agree. There are lots of examples of games with real consequences – Russian Roulette, gambling for money, etc. In game research, this “magic circle” supposedly separating games from the real world is a hotly debated topic.

    What I tried to articulate is that the experience of a situation as *play* or *playful* is a core dimension of the *fun* of games, and that this playfulness has a lot to do with the situation being experienced as a “safety zone” with room for experimentation and no grave consequences, should an experiment fail. In corporate contexts, the success or failure of brainstorming sessions depends a lot on the degree to which this shared ground of “fooling around allowed, no one get’s derided for anything suggested” can be established. However, if an activity is tied to a “hard” real-world outcome, this usually changes the experience and behavior. Playing poker for real money is exciting, but in a different way than playing for mere plastic chips. People feel more stressed, are less willing to experiment freely, etc.

    Stephen Anderson pointed me at, basically an internal knowledge sharing platform for enterprises that also uses game mechanics – and apparently quite successfully. I would argue that this is partly so precisely because the platform does *not* tie your “game performance” to any real corporate reward/punishment systems like quarterly evaluations, cash bonuses etc. Employees are creating valuable real-world outcomes by exchanging knowledge on the platform. But if they knew that a certain level of participation was expected by their management, that it gets monitored and rewarded/punished, this would likely ruin the motivational dynamics – and the social dynamics of a mutual sense of obligation you mentioned. And this, I couldn’t agree more, has everything to do with corporate leadership and culture: understanding that game mechanics are about helping your people to structure their own collective activity better, rather than a new tool of surveillance and control.

    So I would say that “no consequence” (or, more precisely, “no punishment for failure”) is important for the creativity part of play, and that voluntariness, the experience of autonomy is important for the motivation and engagement part of play. Which is one reason why open source projects work – people choose to rather than are assigned to solve certain problems.

    Thanks for helping me think through this ^_^.

  2. You write that a system for knowledge sharing using game mechanics, that appears to be successful in part because “the platform does *not* tie your “game performance” to any real corporate reward/punishment systems like quarterly evaluations, cash bonuses etc.”

    This is a good point, and I think it points to a different issue with traditional corporate reward/punishment systems. There is a lot of evidence that common types of performance reviews and bonuses are ineffective (for example the argument in this book), because among other things they are decoupled from the regular flow in which people work. So, the problem may not be with explicit goals and consequences, as much as underlying flaws with the performance scheme.

    I agree that incentives, personal and organizational need to be well aligned for this sort of thing to work and avoid system-gaming and other unintended negative consequences, and this is hard to do. One of the requirements is an iterative process of design and change – because results will be different than expected, and also because tools and systems themselves catalyze changes in people’s behavior.

    This is a very interesting topic – and much more complex than “just adding points!”

  3. Don’t get me started on “gaming the system” — the moment you reduce a task to a measurable goal, it is likely that people will deliver on that goal to the letter in disregard of (and often harmful to) the actual intention — “hitting the target and missing the goal”. There’s lot of study and evidence on this having happened when measurments and targets where introduced in the British health care system. Another aspect of external reward/punishment systems is that they are often detrimental to intrinsic motivation; Alfie Kohn’s “Punished by Rewards” remains a good primer on that. Deep, fascinating topic, indeed :).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>