What SHOULD we be learning from games?

Chris Massey gave a lightning talk at Business of Software Conference Europe 2014 on the topic of Gamification. In this guest blog post, he revisits his talk, offering further insight into why we should be thinking more like game designers. Video below, followed by Chris’ insights.

[wistia 8xcb5n37ii]

I was privileged to be invited to give this lightning talk at BoS UK 2014 but, upon watching the recording, I realised that I really embraced the idea of a “lightning talk” and spoke improbably fast. If you were there and were struggling to decipher my gabble, I offer the idea in written format.

Depending on who you ask, you’ll get different definitions of “gamification”. The basic understanding is that it’s the practice of applying game mechanics to non-game products to make them more engaging and compelling – making boring (but perhaps necessary) things more fun.

You keep using that word, “Gamification”…

Or, to put it more bluntly, duct-taping game mechanics together without much thought for what behaviour is actually being encourage – just that the product needs to be “more engaging”. The problem with this naïve approach is that it’s like trying to make your ancient old car go faster by strapping a jet engine to it. It might go faster. It also might explode. Either way, it’s not really a car anymore.


Games are just products

Gamification is a made-up word that describes a convenient hack for designing products that exploit features of human psychology to make them more enjoyable, or at least more “sticky”. The hack in question is to copy the mechanisms and interfaces developed by game designers, because games are super-engaging, and we want to make a super-engaging product, so we should just copy what works well, right?


Games aren’t just bundles of mechanics and pretty visuals thrown together to help people pass the time, just as products aren’t just arbitrary collections of features. (Video) games are very engaging software products, with the same requirements and design practices of any other product. Once we recognise and acknowledge that, we can realise that copying form without context or understanding is going to lead to products that – at best – underperform, and at worst result in user behaviour that we don’t understand and can’t control. If this doesn’t make much sense to you, then Des Traynor’s excellent presentation – Product Management is all about saying “No” – is recommended viewing.

The mechanisms and interfaces that make games so engaging work because their designers have a deep understanding of what their users are trying to achieve. All the points and leaderboards and profiles and design decisions that go into good games exist purely because the designers have understood something about what their users want to do, and are helping them achieve it.

What this means for us as people who build software is that, if we want to make our products more engaging, we can’t just “make them like a game”, but instead have to think about the user goals and fundamental product design.


To start with, let’s look at what people think makes games engaging in the first place. A good case is made by Scott Rigby & Richard Ryan, when they argue that good games provide the player with three fundamental things, which echo Dan Pink’s model (from his book ‘Drive’) of what motivates people in general:

Scott Rigby & Richard Ryan

  • Competence
  • Autonomy
  • Relatedness

Dan Pink

  • Mastery
  • Autonomy
  • Purpose

If we add in the idea of “Flow” (and, if you’re designing products, I highly recommend you go and look this up), then we’ve got a pretty good shorthand foundation for “fun” & “engagement”. However, we also have to recognise that what counts as “engagement” varies for different products, and there is no One True Metric of engagement. However you define engagement for your product, it’s only valuable in as much as it:

  1. Servers your customers goals
  2. Gets customers using your product
  3. Ultimately, puts money in the bank.

Now we’re making progress: we’re not talking about game mechanics anymore – we’re talking about tuning products against user expectations.

Fundamental Design > Bolted-on Design

I said at the start that games are, ultimately, just software products – albeit very engaging ones. They are essentially labs where designers can trial and experiment and master the art of holding user’ attention. So, if we’re going to create engaging software products, that means we’ll need to think like game designers, understand why they make the choices they do, and understand the impact and trade-offs they’re balancing.

We’re not going to get there in one setting, but I’m hoping to get you thinking about how your product is designed, rather than how to gamify it. Now, let’s run through four game design considerations and why they matter to software that isn’t a game:

Balancing Depth and Complexity.

In game design terms, Depth can be described as the number of qualitatively different experiences can you get out of your rule-set. So, Tic-Tac-Toe has relatively little depth.

On the other hand, Complexity can be described as cognitive load, or the number of decisions the player is required to make each second (or each turn). So a flight simulator has a lot.

As you can probably guess by now as, as a game designer, you essentially “buy” depth in your game with a certain amount of irreducible complexity and, as a general rule, your design goal is to maximise the amount of depth whilst reducing the amount of complexity. Let’s move this to an example – photo editing software.


I took a photo of some cupcakes, and I wanted to add some blur, increase the contrast a saturation, etc.. The result on the left was done in Photoshop and took me about 5 minutes. The result on the right was done with the Snapseed iPad app and took me about 30 seconds.


I can’t actually tell the difference in the results, but Photoshop is clearly overkill for making photos Facebook-ready. Photoshop and Snapseed both have carefully tuned balances of depth and complexity, simply aimed at different “players”. Just as Photoshop is a professional’s tool, there are plenty of game which are deliberately complex because they’re aimed at people who enjoy the challenge and skill growth of mastering them.

Understand who you’re aiming your products at, and make sure you strike the right balance of depth and complexity for them.

On-Boarding and Tutorials

Of course, you have to have some complexity to create a meaningful experience. Games try to manage the balance via tutorials (the on-boarding process.) Specifically, they try to get the user practically familiar with the rules and requirements of the game in the shortest, most effective way possible (hint: it’s not via the manual.)

There are broadly two approaches to tutorials. The first has an overt initial “tutorial level” with guidance and instructions appearing either from in-game characters or simply from the game itself, breaking he 4th Wall. The second approach – and the original Super Mario Bros is a masterclass in how to do this – is to have level design so well-tuned that the player instinctively grasps the mechanics and rules as they progress.


In terms of the business of software, this is equivalent to giving the user overt hints during their first run of your product versus having a user interface that is so intuitive that explicit instructions are redundant. The latter is considered ideal, but is not always achievable.

I’m not going to tell you how you should design your on-boarding process – merely to point out that many games do it incredibly well. By that I mean that they on-board users in a way which leaves them immediately feeling like they’ve mastered something, and are making tangible progress towards their goals. Or, at least, like they’re getting value from the product right away, and able to figure out what to do next.



Facebook lets you start using the network with a ridiculously small amount of personal information, when you consider how much they ultimately learn about you. You can get value from the network almost instantly and, arguably, their on-boarding process never ends (they’re constantly asking for more information). Microsoft Office applications actually do a pretty good job at presenting you with common options, and then letting you dig deeper in context if you need to. And whole articles have been written about the simplicity and intuitiveness of Google’s interface.

The onus is on you to show your customers how to use your software, and what they really care about is getting results, not mastering your product. Give them what they need in order to succeed, and do it as quickly and cleanly as possible.

Aesthetics and Features as Communication

The visual (and audio) design and mechanics of games are all deliberately designed to communicate something to the player. That might be something about the tone of the world that the game is portraying, or the kinds of behaviour and play-style that are appropriate and rewarded. Let’s take a look at two games franchises which are superficially similar to explain what I mean: the Call of Duty series, and Halo series.


Both are first-person shooters, and both cast the player as a hero against huge odds. However, the aesthetics of the Call of Duty games are tuned to create a sense of realism, bleakness and (I’d argue) cynicism. Muted colour palettes, hyper-realistic environments and weapons, and blood-spatters as you shoot and are shot at. Similarly, your character can’t take many hits before ‘dying’.

On the other hand, the aesthetics of the Halo games are bright, vibrant and saturated, giving a sense of futurism, unrealism and adventure. The player’s character has science fiction energy shields and weapons that lets them absorb and dish out huge amounts of damage while running headlong into combat.

Call of Duty is designed to make you feel like a human being in situations of extreme danger. Halo is designed to make you feel like a nigh-indestructible super-soldier, single-handedly saving the human race. But they’re both “just first-person-shooters”.



To see this outside of games, let’s look at programming tools. Scratch is a programming tool aimed at getting young children interested in coding. The user interface is brightly coloured with large, shape-based programming components, and it enables users to write simple yet effective programs. Everything you see here is tuned to make the customer (children) feel comfortable with the tool, yet also able to achieve technical mastery.

In contrast, you just have to glance at Microsoft’s Visual Studio tool (pictures below), or any other professional development tool to realise that the aesthetics are designed around giving maximum detail about the software being written – focusing on the code itself, minimising any other distractions, and adding a wealth of additional tools to menus and keyboard shortcuts.


What this hopefully makes clear is that everything about your product and about your company is communication, because people will be deriving meaning from all sorts of places, whether you intend it or not.

Every product has a User Experience. It may not be the experience you want or intend, but your users are having it, nevertheless. The challenge is to understand and influence as much of that implicit communication as is relevant and possible, and think very hard about how to create a rapport with your users via your design.

Intrinsic and Extrinsic rewards

You’ve got your product out, and you’ve got paying customers. Now you want them to keep giving you money and, ideally, to tell their friends about your product. In both of those cases, we need to talk about the intrinsic and extrinsic rewards. In very simplified terms,

  • Intrinsic motivators are the internal rewards the game user gets purely through playing – fun, a sense of accomplishment, enjoying a good narrative – they do it because they love it …
  • and extrinsic motivators are the external results they reap by playing – sponsorship, subscribers to their YouTube channel, acclaim in the gaming community.

It’s also important to remember that, because people are a complex jumble of goals and motivations, they will almost always have a mixture of intrinsic and extrinsic motivations for buying and using your product. There is a vast amount that could be said about the importance of understanding the intrinsic and extrinsic motivations of your customers, but there are four things I particularly want to draw attention to:

  • If you have a loyalty program, that’s an extrinsic motivator. At least part of your customers’ buying decisions will be driven by them playing the game that is your loyalty program, rather than loving your product. Maybe you don’t care, so long as they’re buying, but beware of your loyalty program “game” being more compelling that your product itself. If that happens, you might find that changes to your product have less positive impact than you’d hope, whereas changes to your potentially-expensive-to-run loyalty program (such as limiting or discontinuing it) have much more negative impact than you’d like.
    1. Recent evidence also suggests that, in saturated markets where loyalty programs are largely homogenous, customers start to either manipulate or ignore the system (and it may well be too late to discontinue your own program).
  • Your product’s fans and community evangelists *might* be pursuing intrinsic rewards. They may love using it, or love how it makes them feel and look like a badass. Be careful how you incentivise them. Specifically…
  • Beware of replacement. Put very simply, if you replace an intrinsic motivator with an extrinsic one, and then remove the extrinsic motivation, then the original behaviour may also be stopped.
  • Your fans are probably excited about immaterial things. Specifically, they’re likely to be looking for some combination of these things (in order of importance):
    1. Mastery – What Kathy Sierra calls badass users – people want to be highly capable at whatever it is that your product is a part of (they don’t care about mastery of the product in and of itself)
    2. Status – People want to be highly regarded in their community.
    3. Power – People want to be able affect outcomes, and your passionate customers will want to feel like they have some impact on the way your product develops (even if only via their feedback)
    4. Access – The people who love your product may well be excited to meet the team building it, or to hear about what you’re planning in the future.
    5. Things – Customers are generally happy to get free stuff (t-shirts, hampers, discounts), but these things are often tangential to the thing they’re passionate about (they’re probably not evangelising your t-shirts, hampers or discounts)

Know what’s motivating your customers, and engage with them accordingly, knowing how you may or may not be affecting their passion for your product. And yes, this is a stark warning against thoughtlessly bolting game mechanics onto your product.

Game Over for Gamification?

I’ve thrown out a lot of things for you to think about, and now I’ve issued a warning that game mechanics may actually break your customers’ engagement with your product – am I saying we should never gamify commercial software? Not at all. I think that so-called gamification is a tool that enables us to create hugely compelling and well-designed products.

However, I am suggesting that gamification has almost nothing to do with mechanics, and is actually all about a particular design mind-set. Thinking like a game designer, and asking questions about what experiences and processes are a part of your product is what will lead you to create engaging products. Not points and leader-boards. If you want to go faster, don’t strap a jet engine to your tired old care – build a faster vehicle.


User Manuals

Learn how great SaaS & software companies are run

We produce exceptional conferences & content that will help you build better products & companies.

Join our friendly list for event updates, ideas & inspiration.

Unsubscribe any time. We will never sell your email address. It is yours.