Here’s a quick article about the problems Ron Johnson had at JCPenney: Ron Johnson Didn’t Understand Apple. The post is not about playability per se, but at this point in history, “playbility” won’t be what users are asking for. Jobs had it right (and this article parses it well): users know what their problems are, but they don’t know the solutions. That’s our job, and that’s where playability can help in the enterprise.
Enterprise gamification is getting a lot of attention these days (more on that later). The value of gamification is clear enough: engage users and motivate them by providing the same feedback mechanisms that games do. Goal-driven design, the idea that software should be designed to help users achieve their goals, is extremely popular for consumer products, but still only rarely practiced in enterprise environments.
It’s the combination of the two that gets me excited. When enterprise software is designed with full adherence to both of these concepts, the results can be astounding. Imagine software that is built with an understanding of exactly what you need to get done — what you want to do, and what your management wants you to accomplish. And imagine then that the software is built in a way that keeps you engaged all the time, trying hard to get to that next achievement, the next milestone, the next level.
Software, even enterprise software, can be built in such a way that users don’t feel like users, but like players. Work may not actually be a game, but making a game of it could make it so much better.
Here’s a good post with some great comments: Cognitive Overhead, Or Why Your Product Isn’t As Simple As You Think. The topic is cognitive overhead, which is the difficulty users have in understanding a product or a feature of a product. While it’s not directly related to enterprise playability, cognitive overhead and cognitive friction are both faces of usability, and improving both is often done well in games, and often done poorly in enterprise software.
Now there’s a title: “Fighting solves everything.” John McNamara’s post contrasts the reward systems in two games, and clarifies the importance of rewarding team success, versus just individual achievement, in an enterprise environment.
Here’s a great introduction to some of the concepts in enterprise playability (a.k.a. gamification): Is There Value in Enterprise Gamification?. The articles (there are two so far, in what will be a three-part series) touches on the value of enterprise gamification, and also points to a book by Jane McGonigal that would be worth a read.
But the article seems to follow an unfortunate pattern I’m seeing in the industry: There’s an interest in adopting some of the principles of game theory, but it’s a cautious interest, careful not to step into the muddy waters of actual games at work. That pattern is holding back the industry from what could be a powerful change in the way enterprises do business. When we get over the aversion to games themselves, and make enterprise software actually playable, we’ll see an increase in motivation, productivity, and profit.
In Papyrus Achievement Gained! Lance Phillips explores the motivating factors in online writer’s games, and whether or not “gamification” can motivate writers. He asks “Is this actually something worth doing? Would it appeal to budding writers?” I say yes it is, and yes it would. Writers, as I understand it, can only be productive if they spend time at their desks. If a game will motivate a writer to sit down and write, what’s the worst that could happen? Too many blog posts?
Enterprise software’s standard widgets are quite usable. The fact that they are so common has given users the chance to learn how to use them quickly and efficiently. Their familiarity is a huge boon to usability. It’s a pity, though, that enterprise software designers don’t seem to be able to design any widgets outside of the standard set. They prefer instead to make sure everything anyone wants to do, no matter how counter-intuitive the connection may be, fits into a standard widget.
Familiar components may be usable, but they do not contribute to the overall usability of software unless they fit into context of the software. A data grid full of train schedules may look familiar, but it does not help users think about or understand trains, their schedules, or the complexities of managing a train station. A map of the train station could show where the trains are, where they are headed, and when they will arrive and depart. The visual context would offer an intuitive understanding of the situation, and ultimately a much more usable interface.
Rich context makes for an engaging interaction. It reduces the cognitive friction that occurs when a user tries to translate data presented in a standard widget into information that’s usable in the real world. It brings clarity to a situation, and in turn enhances shared situational awareness. If team members can all clearly visualize the environment they are working in, they can easily coordinate their actions and work out solutions together.