Triplebyte Blog

We help engineers join great companies
Try our coding quiz

Share this article The Importance of Game Design (not Gamification) in Software

By Daniel Bean on May 14, 2020 The Importance of Game Design (not Gamification) in Software

This is, a Q & A series by Triplebyte where we ask software professionals to go deep on a technology or work practice they use and know well.

For this edition, we spoke with Superhuman CTO Conrad Irwin about how game design makes software better, how it’s different from gamification, and what skills engineers should learn to build it into their projects.

(The chat below has been edited for clarity and brevity.)

Let’s start by talking about how game design and gamification in software are not the same thing. What are the important differences?

I would say this at the top: Gamification — as it is widely understood — does not really work!

Game design works well, but game design is not gamification. It is not simply taking your product and adding points, levels, trophies, or badges.

To understand why gamification does not work, we have to understand human motivation. There’s a very interesting study, conducted in Stanford, that demonstrates the difference.

The researchers collected a number of young children who were interested in drawing. Half the kids were promised a reward, and half of them were not. In fact, second group of kids did not even know that a reward existed. Then, each child was invited into a room to draw for six minutes, and either presented with the promised reward or not.

Over the next few days, the researchers monitored how much the children continued to draw by themselves.

The children with no reward spent 17% of their time drawing. Surprisingly, the children who received a reward spent only 8% of their time drawing. The reward had halved their motivation!

So what does this have to do with gamification and game design?

Researchers differentiate intrinsic and extrinsic motivation. With intrinsic motivation, we do things because they are inherently interesting and satisfying. With extrinsic motivation, we do things to earn rewards and achieve external goals. And that’s the problem with rewards: they massively undermine intrinsic motivation.

What makes gamification more effective?

When gamification seems to work, it is because the underlying experience was already a game. The question really becomes: How do you design a great game?

At Superhuman, we have studied this question intensively. And we have found that there are five key factors to consider: goals, emotions, controls, toys, and flow.

For example, let's think about toys.

Are toys the same as games? Not really: We play with toys, but we play games. A ball is a toy, but tennis is a game.

Yet the best games are built with toys. Why? Because then they are fun on both levels: the toy, and the game itself.

In Superhuman, my favorite toy is the Time Autocompleter, which you use to snooze emails.

You can type anything into the autocompleter – it can be nonsense – and it will do its best to decipher what you meant. For example, “2d” becomes two days; “1mo” becomes one month.

The autocompleter is fun because it indulges playful exploration. If you ever ask yourself questions like, What can it do? Where does it break? How does it work? then you are playfully exploring!

When you start using the autocompleter, it’s not long before you ask something like this: “Hmm… I wonder what happens if I keep typing 10?” It just works — that's October 10th, at 10:10 pm!

“How about a sequence of 2s?” That works, too — it’s February 2nd 2022, at 2pm!

And soon, you find pleasant surprises. “How about in a fortnight and a day?” Also works! “How about 8 am in Tokyo?” Not only does this work, it does the timezone math for you!

Consider features of your own product. Do they indulge playful exploration? Are they fun even without a goal? And do they create moments of pleasant surprise?

If so, congratulations! You have a toy, and you're on the way to building a great game.

Conrad Irwin quote.png

On the software engineering side, are there special skills or backgrounds that serve best when practicing game design?

You don’t need any kind of special background. Designing great user experiences is central in building any software – but that's true whether you're building APIs for other programmers, user interfaces for less technical users, or even a system your later self has to debug!

You do want people who interact with your software to feel good, and game design is a great way to do that.

It helps to develop your vocabulary for emotions. Should people feel relaxed or satisfied? How do you avoid people feeling discouraged or irritated? You can practice by naming your own feelings, or mapping people's feedback to the feeling that produced it. (At Superhuman, we use this Emotion Wheel by the Junto Institute.)

It helps to develop your understanding of human-computer interaction research. For example, we know that people perceive interfaces that respond in 100ms to be instant, which is one of the reasons why games take responsiveness extremely seriously.

Finally, and maybe clichéd, it helps to play games! As you play, think about how you feel. Notice when something makes you feel relaxed, excited, or amused. Can you pull that thing into your software?

How about specific tools or programming languages?

I don't think programming languages can help much! They're just tools to help you and your team collaborate on the experiences you want.

My standard advice for picking languages or frameworks is to find a large, healthy, community and then follow the best practices there. The two primary factors to consider are the ease of finding the answer to any question you may have, and the ease of hiring people who already know the language or framework.

There are some mental tools that do help. For example, there is nothing like intentional practice. If you want to make a game, make a game. Start simple, so you can learn rapidly. You could build pong in one day, and then spend a week trying out ideas to make it more interesting, or silly, or fun. The important thing is that you try lots of ideas and get a feel for what works and what doesn't.

Lastly, it is essential to develop a mechanism for constant feedback so you can see whether your design choices work. For the first few years at Superhuman, every single employee was CC'd on every single email to or from a customer. This turned out to be super effective: We learned very quickly about changes, both small and large. Nowadays, the volume of user email is too high to do this. So we have developed a system to record user feedback, verbatim, in GitHub and Airtable. Whenever we work on any issue or a feature, we can all quickly read hundreds of relevant comments in the original words of our customers!

Is there a genre of software that could really benefit from game design? And if you were an engineer, how would you start applying it?

Today, most business software feels like work. It's because real game design — as opposed to just gamification — is rarely used in it.

Most business software companies worry only about what users want or need. But nobody needs a game to exist; there are no requirements.

When you make a game, you don’t worry about what users want or need, you obsess over how they feel. This means: When your product is a game, even if that product is a piece of business software, people don’t just use it — they play it. They will find it fun, they will tell their friends, they will fall in love with it!

If you're excited to learn more, I would start by watching this talk from our CEO Rahul Vohra: Game Design, not Gamification. He covers the five critical factors of goals, emotions, controls, toys, and flow — and the seven principles of game design that come from them.

If you’re interested in going even deeper, read The Art of Game Design by Jesse Schell. This is by far the best book on the topic!

And if you’d like to learn more about how Superhuman uses game design, you can email him here or find him on Twitter.

Get offers from top tech companies

Take our coding quiz


Liked what you read? Here are some of our other popular posts…

Triplebyte’s Way-Too-Long Technical Interview Prep Guide

By Triplebyte on Apr 29, 2020

A running collection of technical interview preparation resources that we've collected at Triplebyte.

Read More

How to Pass a Programming Interview

By Ammon Bartram on Apr 29, 2020

Being a good programmer has a surprisingly small role in passing programming interviews. To be a productive programmer, you need to be able to solve large, sprawling problems over weeks and months. Each question in an interview, in contrast, lasts less than one hour. To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. This is a different skill. On top of this, interviewers are often poorly trained and inattentive (they would rather be programming), and ask questions far removed from actual work. They bring bias, pattern matching, and a lack of standardization.

Read More

How to Interview Engineers

By Ammon Bartram on Jun 26, 2017

We do a lot of interviewing at Triplebyte. Indeed, over the last 2 years, I've interviewed just over 900 engineers. Whether this was a good use of my time can be debated! (I sometimes wake up in a cold sweat and doubt it.) But regardless, our goal is to improve how engineers are hired. To that end, we run background-blind interviews, looking at coding skills, not credentials or resumes. After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe). We interview engineers without knowing their backgrounds, and then get to see how they do across multiple top tech companies. This gives us, I think, some of the best available data on interviewing.

Read More