I love watching documentaries, and Netflix feeds that pastime nicely.
Over the past few months, “Indie Game: The Movie” has been bouncing around my head. I’d heard of it by way of several blogs I read, and I nearly bought it from iTunes to watch on a plane ride. This weekend, I saw it was on Netflix and finally got down to watching it.
Incidentally, this movie is an early Kickstarter success, so there’s that.
Moving on, this won’t be a movie review. I’ll leave that to Tim (@oraclebase). Instead, I’m focusing here on some nuggets that I took away from watching the film, which was truly entertaining and a fascinating watch, even if you’re not a gamer, which I am not.
Since SXSW 2010, I’ve gravitated toward the parallels between game development and traditional software development. Both involve producing lots of code, but games are seen as entertainment, which changes the design and production processes dramatically. Games are overseen by producers, akin to product managers, but the title difference is key.
The term producer conjures images of movies or TV shows, forms of entertainment. Entertainment exclusively focuses on user experience; this creates a much more intimate connection with the person on the other side of the software, something from which I think traditional software can benefit.
Creating a connection with software used for work sounds a bit silly, but I think this is a difference that could help keep customers. Engaged users who really want to keep your software because the enjoy using it could tip a purchase decision as much as a price difference.
So, I watched “Indie Game” for entertainment and to learn about game development.
The movie focuses on independent game producers, i.e. not part of a large studio, specifically the tiny teams behind Braid, Fez and Super Meat Boy. In reality, these are teams of two people, or in the case of Braid, one guy. Looking at the complexity of the games they produced and the monumental effort required, I’m reminded of the tales of companies like Microsoft and Apple. Unlike the startups of the Internet age, small teams used to produce finished products before getting any money.
Here are the main nuggets that I took away from the movie.
Purity in Design
Game design is pure and remains so because of laser-focus on the gamer. The designer’s empathy with the gamer creates a Zen-like product, and that emotional bond creates fantastic user experience. How can I replicate that for traditionally antiseptic software design?
Gameplay as Instruction
Gameplay as instruction is gold. Edmund McMillen (@edmundmcmillenn), the designer of Super Meat Boy, walks through this design concept in a segment called Level Design, which begins about 34 minutes into the film. The concept is simple: no one reads instructions. So, you build the game levels around basic concepts and build incrementally, using reminders, and the player learns how to play the game successfully.
Nobody will RTFM, so adding game mechanics to software training has become a new way to instruct new users. I’d like to push that into real use because training wastes time, and no one likes it. So, why not train users by use and let them level up without even making a bid deal out of it?
Process easy invoices first. Close the single ledger, single currency, single legal entity books first. Match the simple purchase orders first. Upload personal files first.
After you do the easy stuff successfully, you graduate to slightly more difficult tasks. No badges, no kudos, just work. The game mechanics just work in the background, and the advanced users roll right along, while the n00bs get retrained until they’re ready.
There are inherent risks to this approach, but it has merit and engages the user without overtly gamifying the experience.
Don’t Get too Close
Users, like gamers, are unpredictable. They will do things you didn’t expect and focus on aspects of your product that surprise you.
Don’t get too close to the product, or you won’t be able to let go of a decision because you’re emotionally attached. This is this “Heat” problem, coupled with a side of haters gonna hate.
Beyond what I learned, “Indie Game” is a portrait that looks back at some of us. The painful obsession with creating something, the emotional connection with something you’ve created, the uneasiness of seeing people use your product, the reminders of what is was like to grow up a nerd, all of these things touched a nerve.
Sure, I haven’t designed and built something as complex, but I can relate. It’s empathy.
Wow, I never intended to spend so many words. Anyway, I wholeheartedly recommend watching “Indie Game” whether you’re a gamer or not.
Find the comments.
It’s a pity that the starting tutorials that are built into many games haven’t been adopted by traditional software.
I am now a volunteer for a certain national organization, one that has its own website that the volunteers must navigate, and various forms that the volunteers must fill out. Things would be much easier if a cartoon character would guide me through the website and the form-filling process. Instead I have to listen to pre-recorded training sessions (“then you select ‘Done’ in the lower right corner”) that are divorced from the application itself.
Interesting. I’ve seen many examples of adding game mechanics to tutorials, mostly creating quests, and these are good.
What I like best about the level design approach is that you learn by doing, no extra effort involved, which makes you immediately productive w the product. This efficiency savings is huge for new software/service adoption.
Plus, I’d wager that younger users would take much more easily to this approach than to the more traditional, teach first, then use, even w a good quest.
Another useful biproduct is that as you use, you level up to harder tasks, which is a great indicator for performance. Stuck on a level, then take the training.
The biggest hurdle is taking apart a product, distilling it into discrete tasks, ranking them by difficulty and then rebuilding. To do this right, you don’t have a choice. And of course, you have to provide training too for those who want to learn that way.
http://www.time.com/time/specials/packages/article/0,28804,1991915_1991909_1991755,00.html (sorry, I couldn’t leave it go)
I assume you know they tried again w Ribbon Hero http://www.ribbonhero.com/news.html. See my comments about the advantages of the level design approach.
And there are also advantages from the user having more control of the experience. I wonder how the competitive aspect of Ribbon Hero 2 is executed; do you get Outlook messages saying that Peter just beat you in Ancient Egypt?
Not sure how it works and haven’t played it, but it’s always cited by gamification pundits as a good example. So, whatever that means 🙂
Jake,
This is in my netflix queue – but I know level design and I agree there are areas where this can be added to enterprise software. Also when I implement for example a new ERP system, I will do a Conference Room Pilot or two and User Acceptance testing before Go Live – these tend to level up in complexity, so we should build on that. I think I need to pull you into something else I’m working on with one of your UX colleagues,
Let me know what you think of it. Interesting stuff.