5 Lessons UX Designers Can Learn From Game Development

Game development and web development have more than a few things in common. Specifically—if you’re lucky—you’re developing a product that will be seen and used by thousands, if not millions, of people on a regular basis. You’re going to need a good team, good quality assurance, and whole lot of support staff to answer questions. You’re going to need god-tier servers. You’re going to hear a lot of complaints that range from constructive criticism to outright petulant whining.

Gamers are a rather demanding audience. Many companies often hide their development and project management processes behind a veil of secrecy (and sometimes outright shame) sticking mostly to press releases. Game developers are usually a bit more transparent. This isn’t because they’re morally superior. It’s because their customers are willing and able to raise hell if they think things are going in the wrong direction.

[pullquote]You’re going to hear a lot of complaints that range from constructive criticism to outright petulant whining[/pullquote]

As a result, we can learn a lot by watching the ways different game developers handle their projects, and their relationship with their communities. They don’t tell us everything, but they often do go into some detail about their process, their intentions, and their vision. Also, they put out fairly detailed patch notes, which is cool.

The two games whose ongoing development I have followed the closest are Overwatch, and Dungeons and Dragons Online. I’ll be using them for my examples.

1. Be open about your intentions

The developers of Overwatch have very clear goals in mind for everything they do. They publically state what they want to accomplish, and they go for it. Their actions consistently show determination to meet all of their stated goals. They don’t always pull it off, but they sure as heck try hard.

You can adopt the same strategy: Tell your users exactly what you’re aiming for when you make a change, or new feature. Don’t give them vague mission statements like, “We want to be more efficient, and less not-efficient.” Tell them exactly how you intend to make your service more efficient. Give details. Believe me, it makes all the difference between the users believing you, and saying, “Yeah. Sure. I’ll believe it when I see it.”

2. Correct your mistakes

DDO has a bug with its ladders. Sometimes you can’t climb up them past a certain point, and other times you can’t even grab onto them for a few seconds. This is partially due to lag, which affects all online games. But sometimes, even when every other system is working fine, with no lag, the ladders just don’t. The devs have claimed that they’ve fixed this bug as many times as they’ve denied its existence. Even now, it’s not on the list of known issues.

The users, however, know it’s real. The bug has gotten their characters killed often enough. If most of your community tells you something is erratic on your site, they’re probably right. Even if you have trouble reproducing the issue, you have to keep looking. Your users’ trust in you depends on it.

3. Document everything

Part of the reason they can’t find or fix some bugs in DDO is because the game is over a decade old, and many (if not all) of the original developers are long gone. There are so many systems and features in there that are only half-finished in the first place, it’s a miracle when they can find bugs to fix them.

[pullquote]It’s not just about commenting your code, it’s about documenting your decisions[/pullquote]

If you want to avoid the same problem, start documenting. It’s not just about commenting your code (though that helps), it’s about documenting your decisions. Every decision you make about your project, every new feature you start work on, it should all be in an easy-to-find file somewhere. Your reasons for making the change, or reverting it, altering it, or not finishing the feature, this should all be in there. Also, you should write down where to find all of the relevant code for each new feature or change.

A lack of this kind of documentation leads to unforeseeable—and sometimes nearly unfixable—bugs.

4. Play your own game

Overwatch’s development and management team play the game. This is a known fact. And they’re not all pros. They have employees playing at every skill level, which means they get to experience the game as it appears to low-level and high-level players. This means they can more easily empathize with their user base.

One of DDO’s staffers (who shall not be user-named) is routinely mocked in the community because he can’t keep up without turning on god mode while he streams the game. Also, he uses potions to heal himself, and potions are…not great in DDO. No one’s expecting him to be the best, but they do expect him to know the mechanics of the game better than that. And they expect him not to use god mode.

This principle is also called “eating your own dog food”. You should be confident enough in your own product that you yourself use it daily. This principle applies more to apps than, blogs, for example, but it’s important to remember. If your users see that you wouldn’t use your own product, they’ll wonder why they should.

5. Don’t alienate the ones who came first

This is a problem that has affected DDO, pretty much every other MMO out there, and may even hit Overwatch one day. Essentially, sometimes game developers will more or less destroy the very thing that attracted their original audience. Sometimes they try to attract new players by changing the mechanics, only to ruin the core gameplay. Sometimes they just go and make everything that the original gamers worked so hard for obsolete. Sometimes their new monetization efforts upset the balance of game.

Sometimes they try to base their game on D&D 4th Edition, which everyone hates.

Oftentimes, these changes do bring in new players for a little while. But they usually don’t stay that long, and in the end, the game has fewer hardcore fans than when it started. And then sometimes, big changes can revitalize a game completely.

[pullquote]You’ll never make everyone happy, but there’s a lot to be said for keeping the old-timers around[/pullquote]

Before you make any massive, sweeping changes, talk to your hardcore users. Talk to the people who might depend on your app for their everyday business. If you have a small feature that not many people use, ask those people who do use it how important it is to them. They might depend on it.

You’ll never make everyone happy, but there’s a lot to be said for keeping the old-timers around. From a moral standpoint, you owe them some consideration. They made your product what it is today. From a practical standpoint, fans and users can sometimes have a better idea of why people love your product than you do. They might be wrong, but you’ll never know if you don’t listen to them in the first place.

Ezequiel Bruni

Ezequiel Bruni is a web/UX designer, blogger, and aspiring photographer living in Mexico. When he’s not up to his finely-chiselled ears in wire-frames and front-end code, or ranting about the same, he indulges in beer, pizza, fantasy novels, and stand-up comedy.