This is Expert.info, 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.

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.