Gamification?

One recent buzzword that I hear a lot is “gamification”. Especially gamification of utterly boring Enterprise Software and consumer experiences in commercial transactions. A heroic attempt to solve one of life’s mysteries; why work sometimes drifts towards boring and in particular why ESW tend to be so unimaginative.

On the surface it looks like nothing but a positive thing to do, who can protest the use of words like “game” or “fun”? It might even throw a dyed-in-the-wool sceptic like myself off the scent, a scent of potentially fallacious assumptions. But heretics have warning bells ringing when something sounds that good.

What triggers my scepticism is the “verbification” of the noun indicating that you take something existing, without challenging the assumptions nor changing the underlying, then simply… eh… gamify it. If the underlying part is not good enough, adding, combining or tweaking really seldom works well, history is full of examples from clunky flying cars to walking machines with wheels (Segway anyone?).

I even get this image of the Louis XV court at Versailles – infrequent bathing and worse, all doused by perfume in a feeble effort to cover the lack of some basic concepts. Sorry for that image, could not resist.

The purpose of “Gamification” seems to be to cover up some manual and tedious process in an effort to make it more “fun” (that word makes me double suspicious). I see it being applied as a fix-all in business settings for one single purpose; get the user to use what he’s supposed to use without having to flog him. A classic manager and now IT vendor quandary.

But what about checking the original assumptions and see if not the tedious and manual part could be removed instead of being hidden under a new “fun” layer? Try the soap before the perfume so to speak?

The better solution

Games could give an answer, no doubt, but the question is; what to learn from games, what works and what is the core? Then apply the core learning to Enterprise Software instead of adding a flimsy layer on top.

Disregarding puzzle games for a moment; games are often about a narrative, a story, with characters to know and conflicts that shall be solved, and it must allow decisions and meaningful choices, still with uncertain outcomes that spurs reactions and results moving the story forward another notch in unexpected directions. Note the word “direction” there.

In short story dwelling instead of story telling; play the game, live the life, immerse oneself in a sequence of partly self directed activities with a meaning (aka process, or indeed work).

Sounds like simulation does it not? Sounds like a real work process stripped of the boring stuff does it not? And indeed it is, both.

But simulation of real life processes, which equals an opportunity to run those, requires a “process engine” that can deliver any sequence of activities and punt back the resulting reactive activities. Manual wiki’ish dashboardy, send-mail-from-Word, or browse and select from long to-do lists does not cut it. Look instead to any multiplayer game on the net and that is precisely what you find at the back end; a pure process engine.

That’s what most Enterprise Software for Barely Repeatable Processes lacks, they’re mostly manual, no underlying process engine, no instantness. Rebuild the BRP ESW on top of a real process engine, take away that tedious, boring and repetitive manual flow-work, automate the flow-work and let the user focus on what’s happening, what to do now at this precise moment, manipulate the process in the quest for solved issues and done work, in short focus on the work story.

That would create real world stories, that would be living the life story, that would be the most effective work modus, and that would be the ultimate game.

Related articles