What Video Games Teach Us about Improving Enterprise Applications

I like video games.  But I like thinking about video games, not just playing them. And I think that if we thought about IT the same way we think about games, there’s a lot we can learn. I’m not talking about “gamification” – where we create achievement and level-up systems for filing reports, optimizing networks, or increasing production. I think that what we can learn from games is much deeper than that.

One of the things that will separate a mediocre game from a great one is that the great games present you with opportunities to learn by doing. Take Mega Man, for instance, where all of the game elements are introduced in a controlled environment during the intro stage, where you can experiment and learn the entire game by doing. It’s not a tutorial, you just play the game.

Some of the best games ever made follow this model.

I think the best enterprise applications should be designed with the same ideas in mind. It may not be practical to drip-feed new features in software the way well-designed video games teach you new game mechanics, but the key should be that the end user can learn by doing. With the exception of applications designed for automation, an application is only productive if people use it and use it well. The less steep the learning curve, the more value the user derives from it. As humans, we derive pleasure from improving our skills.

So, designing in a way that enables people to learn the application by using it will encourage them to use it more, which encourages them to learn it better, which will encourage them to use it more, which will help them use it better and… seriously, there should be a phrase that means “good version of a vicious cycle.”  Do the Germans have one? (Maybe “Lernvergnügen” or “fun to learn?”)

Now that doesn’t mean that you shouldn’t make applications with a lot of depth to them. It’s just that that depth is very different from complexity, and that elegance in game design – and, I would argue, in application design – is using a minimum of complexity to create something with the maximum of depth.

Anyway, depth is measured by an end user’s ability to make meaningful choices with the options presented to them. Complexity, on the other hand, is defined by the difficulty of accessing or understanding those options.

Now, complexity isn’t a deal-killer, but the more brain juice (a medical term, I’m assured) that users have to use dealing with the complexity of the application, the less brain juice they have to explore the options of the application. With this in mind, Packet Design has moved its product suite to a workflow-based Web UI to make it easier for a range of users (networking experts, novices, managers, operations teams, engineers, etc.) to take advantage of its functionality. Route and traffic analytics combined with performance for network assurance just got a little easier.

So, yes, even in the most specialized of fields, a good, intuitive UI does make a difference. Quite frankly, if you’re designing an application to, say, control a nuclear power plant, you do not want your end users thinking about where the “stop meltdown” button is; you want them thinking about how to stop the meltdown.

Really, when you think about it, there’s not that much difference between an enterprise application and a video game. Except you can’t shoot people with lasers in an enterprise application. (Unless there’s something at DARPA that I don’t know about.)