Directory of All Essays

Tuesday, January 19, 2010

Ribbon Hero turns learning Office into a game


This post has two goals. One, I want to share with you something amazing; a thing that according to most views of the tech universe should not exist. Two, I want to talk about a coming revolution in application design.

The amazing thing
Imagine Microsoft Office turned into a video game. One where learning a productivity app is a delight. One where the core loop of gameplay involves using and gaining skills in Word, Excel and PowerPoint.

It sounds a bit unlikely doesn’t it?

Well, I’m happy to announce the availability of Ribbon Hero, a new download from Microsoft that turns using Office into a game. I’ve been helping the fine folks over in Office Labs with the design and we are all immensely proud that this is getting released to the public. Huge kudos to Jen, Jonas and the rest of the team. CNET calls it "Brilliant".

Go download it now. You can challenge me on Facebook with your elite formatting skills.

The coming revolution
Ribbon Hero, in part, was born from a speech I gave back in October 2007 on applying the design lessons of Super Mario Bros. to application design. I made the following bet:
  • If an activity can be learned…
  • If the player’s performance can be measured…
  • If the player can be rewarded or punished in a timely fashion…
  • Then any activity that meets these criteria can be turned into a game.
Not only can you make a game out of the activity, but you can turn tasks traditionally seen as a rote or frustrating into compelling experiences that users find delightful.

The foundations of user experience design are incomplete
Games offer a very different value proposition than what you get from traditional usability design. The essence of modern UI design is summed up by usability guru Steven Krug’s proclamation “Don’t make me think!” We are taught, as UI designers, as website developers and as software creators that our target user is a shallow dullard. The prototypical user is presented as incapable of reading, barely cognizant of what they desire and are best served by products that offer a least common denominator feature set.

This user model is well supported by empirical data. Sit in on any usability test and your subjects will flail about, click on the wrong things and ignore most obvious visual cues. We assume that users are idiots because we see them behave like idiots whenever we test them.

The results of our current design philosophy are wonderfully simple apps that allow new users to perform one or two universal tasks in as streamlined a manner as possible. These are the Googles, the Twitters and the Diggs of the world. They focus on ease of acquisition and limit their functionality to the 20% of features that serve 80% of the population.

Yet, as applications grow, the “Don’t make me think” philosophy stumbles.
  • Users grow. Given the opportunity, new users rapidly become intermediate and expert users.
  • Different users, especially skilled users, want to master different tasks. Finding one or two universal tasks that matches all users is nearly impossible.
  • New opportunities emerge. As both the developers and the users gain experience with the software, they discover new use cases and tasks that create immense user value. Many developers are faced with the task of either bolting on new use cases or creating entirely new software, fragmenting their brand and user base.
Google Documents is slowly becoming just as much of a usability monstrosity any major text editor (Notepad excluded). Even apps that offer a more limited creative palette such as Mint.com, Ebay and Amazon try desperately to maintain their simplicity. We attempt to leverage pre-existing skills. We carefully layer beginner, intermediate and expert functionality. We use the democracy of split testing to eliminate minority use cases.

Yet, despite the fact that Web 2.0 started with a fresh new philosophy of minimalism and a clean slate, it is rapidly converging on the same frustrating and complex usability solutions found in desktop applications. The current state of the art is missing something fundamental.

Game design focuses on improving user skills
Game design, as applied to application design, brings several powerful ideas to the discussion that are either missing or underrepresented in existing descriptions of UX design.
  • Users are learning machines: All users have immense inherent potential to learn and master new skills.
  • Exploratory learning is fun: Given the proper environment, users will, of their own free will, explore an unknown task. They will try, fail and then finally gain enough insight that they grok the core problem at an intuitive level. When this moment of mastery occurs, users smile.
  • Exploratory learning can be engineered into repeatable systems: Moments of delight and skill acquisition are highly reproducible. All you need is a well designed and balanced system of interconnected feedback loops that helps guide and encourage the formation of new skills.
  • Learning in games is both modular and user directed: Once you have techniques for reliably teaching users new skills, you can modularize your application and let users decide what they want, when they want it and how much that matters to them.
If you start with the idea that users are learning machines, all our observations about usability tests snap into place. Of course, people stumble when they use an application for the first time. They don’t understand the interface because it is new to them. And users will stay at that inexperienced level if we do not make an attempt to teach them how to improve. We’ve diagnosed a burbling baby as a hopeless invalid, blind to the fact that babies grow, learn and flourish.

When users play a game, they spend hours first slowly building up basic skills. Then they assemble these building blocks into complex stratagems. Ultimately, they expertly wield the systems of the game like a finely honed tool. By the time the game ends, the player is no longer the same beginner that started. The design of the game directly helped improve their mental model of the world in a profound and measurable manner. The whole time, the player is having fun.

To me, the rich lessons of past 30 years of modern game design are lessons about human potential. Let’s start with the assumption that people are amazing. We have built pyramids. We have created clockwork contraptions that move mountains and measure the universe. Every day, we navigate a crazy quilt work world of technology, geography, language and culture. Surely we are capable of more complex interactions than typing a word in a plain vanilla search box.

Instead of only treating our users like idiots, how can we follow a design philosophy that actively empowers our users to fulfill their vast potential? The techniques gleaned from game design are one very meaningful path worth exploring.

Practice matters more than theory
Now, it is one thing to talk about how game design can improve application design. It is a completely different task to grab a hold of Microsoft Office, the epitome of traditional application design, and turn it into a playable game.

Ribbon Hero is not the best game in the world. Not yet. However, even in its basic state, it does all the wonderful things that games do in the context of one of the world’s most used, most serious applications. People learn. They improve. And they enjoy the process. Such a highly valuable class of user experience has eluded traditional design for decades.

If these miracles can be done with Microsoft Office, how might game design change the applications you want to build in the future?

take care
Danc.

References

Labels: , , , ,


Read more!

Sunday, February 04, 2007

One Billion Buttons Please: Should we build features for experts or newbies?

I just returned from a lovely evening sipping flasks of yogurt-soju cocktails followed by a wobbly post-beverage walk in the brisk wet Seattle air. It is on libationary nights like this that I find myself musing about interaction design. Certainly, such behavior must be an incurable disease rooted deeply in the nerves at the base of the spine, but after this much alchohol, I can't help but give in.

Tonight's stream of thought kept returning to the question: What level of expertise should we target with our product feature? On one hand, web savvy designers swim in a warm sea of learned gurus preaching the religion of simplicity; how it entrances new users, increases our reachable audience and leads to happier customers. At the exact same time our expert users, the ones paying the bills, are screaming for cybernetic time travel juggernaut creation tools complete with one billion intricately labeled switches.

Balancing the tension between new users and expert users need not be a painful task. Here is a simple framework that I’ve used for many sober years to help me make these decisions more easily.


Layers of mastery
First, I always imagine a program of consisting of three distinct layers of functionality.
  • Intro: First are the features that are encountered when a new user is introduced to a workflow or scenario for the first time. Often these features require only basic, common skills to understand. .
  • Expert: Next are features targeted at the expert user has mastered the workflow and is looking to use the tools provided in an efficient and effective fashion. Expert features require the mastery of several new skills from the user, but they pay off with improved productivity.
  • Meta: A meta-feature help extends the capabilities of the product in new directions. Meta-users use functionality like API and construction sets to better serve newly discovered needs that are not directly served by existing expert or intro features. The presence of meta- features enable lead user scenarios and open up entirely new and unexpected markets.

An example
For my last product, a 3D multimedia application called Anark Studio, we were in a tricky situation. Most of our initial users did not like programming, yet they were hell-bent on building complex interactive applications. In response, we created three basic layers of usage.
  • Drag and drop behaviors
  • Core expert concepts
  • Program it yourself
Intro: Drag and drop behaviors
At the intro level, users could drag and drop pre-created behaviors onto objects. If they wanted a cool mouse over effect, they just drag one out of the gallery and dropped it on their object. The only skills the user needed to know was how to read an how to drag and drop. We made sure all the defaults on each prepackaged behavior were set to something reasonable, the names of the behaviors were easy to understand, and the results were instantaneous and visible.

New users found this functionality amazing since it broke their preconceived notion that all interactivity required programming. The low barrier to entry helped users overcome much of the fear of failure and lost time that naturally arises when they encounter a new application.

Expert: Core concepts
Some users stopped learning at the intro level, but most were engaged enough to dabble in more complex tasks. In order to provide them with more powerful tools that opened up creative possibilities, we introduced to the users three additional core concepts called slides, actions and symbols.

When providing tools for the expert to master, you can’t simply throw the kitchen sink at them. If you provide a hundred tools that all operate differently, you’ll find the most of them go unused. I’ve found that most expert users are only willing or able to learn 5 or 6 core concepts. These are of course the same users who are asking nuclear powered button tool chests. The trick is to bundling variety of tools together using a familiar metaphor. This allows you to teach one concept that opens up multiple capabilities.

For example with slides, most of our users were familiar with slides in PowerPoint. Even though we really were dealing with a rather powerful state machine full of unique persistence and animation constraints, the familiar metaphor helped them bridge the gap to practical usage quite quickly. They could immediately add, remove and rearrange slides. Only after they were using the slides to create interactive states did they start to notice the unique aspects of our implementation.

Add core concepts and their associated metaphors with great care. You’ll be living with them for many years as you build on new features within the conceptual framework that your users have learned.

Meta: Program it yourself

From the very beginning, we also told users that they could double click on any behavior and edit its underlying code. Every control in the application was build up from atomic elements and we gave the user full access to everything under the hood.

Now, they could certainly dabble in creating new behaviors by modifying our existing samples. However, in order to truly build new behaviors, they needed to have mastered all the expert features to an intimate level. Objects models, property publishing, custom events and all concept unique to the inner workings of an Anark behavior all were required to build new objects that extended the system. At the meta level, users were willing to put up with a lot of learning. They had invested heavily in the program and were excited to extend the application in a myriad of ways.

Early versions of Anark Studio had only a few intro and expert features. However, the existence of meta features allowed users to create a truly impressive set of additional capabilities ranging from new animation techniques to physics systems to large scale enterprise hooks. Many of the subsequent markets where Anark found success were a direct result of the customer driven innovation that formed around the meta features of the program.

Paying it forward
Another lesson that was has stuck with me is that you gain a lot by allowing the efforts of meta-users to be bundled up into modular items that can be used by both expert and intro users. All the code they wrote could be turned into simple drag and drop behaviors. Not only do your meta-users extend their own capabilities, but they also can extend the capabilities of the other users of your application.

Hints for using the model in real world situations
My favorite models are ones that allow me to ask hard questions about a design.
  • Do I have a good balance of intro, expert and meta features? Often I’ll find that I ignore a category in a design. Lack of intro features kills my potential market size. Lack of expert features hurts my chances of having a dedicated core audience. Lack of meta features builds the product into a corner, does not leverage customer contributes and reduces future flexibility.
  • Am I classifying my features correctly? Sometimes someone will place a very cool and powerful feature smack dab in front of intro users. The few users that make it through the gauntlet are delighted, but the rest disappear without a whimper. You rarely hear from the users that find your product too difficult.
  • Am I managing conceptual complexity? Am I use a few key metaphors that are readily accessible to my target audience?
  • Do my meta-features empower intro and expert users? If you fail to take this final step, the 1- 5% of your users that a meta-users will end up creating their own isolated community that fails to expand your market and take the burden of creating features off your shoulders.
Answering any one of these questions correctly can have a major positive impact on your product’s success, be it a website, a desktop application or a game. Ask them early and ask them often. Do not be afraid to adjust your design if the answers are not satisfactory.

Conclusion
Used correctly, this simple model of mastery layers goes a long way towards creating balanced applications that serve all your users. It never has been about only serving clumsy newbies or only serving the button fetishists. Such a dichotomy is silly. If we step back from all the blathering, it is obvious that intro, expert and meta users are all quite potentially the same person, just at different stages of experience.

Building products that take into account mastery is really a technique for ensuring user delight throughout their entire life cycle of usage. From the first intuitive inaction with the application all the way to the find stages where they play your application like an instrument, we are charged with making our user’s experience chock full of pleasure and value. Each stage matters and we ignore them at our own peril.

Hydrating with tea,
Danc

References
  • www.anark.com
  • http://www.jnd.org/dn.mss/simplicity_is_highly.html: An interesting take on simplicity by Don Norman. I've run into this many times myself. the problem with making something that is easy to learn, but hard to master is that users often don't realize how much power is at their finger tips. In some sense what many users are asking for is something that *looks* powerful, but is very easy to master.
  • http://www.joelonsoftware.com/articles/fog0000000020.html: Joel on simplicity. Another interesting argument that basically says "All those features are great and computers are advancing fast enough to deal with the increased complexity."



Labels: , , ,


Read more!