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".
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?
Last Thursday, I gave a talk on game design to the local Seattle chapter of the IxDA, an interaction design group. About 100 folks were in attendance and the catered finger food was downright delicious. Other speakers included George Amaya, who spoke about recent research on social/party games, and Mark Long, CEO of Zombie. Mark gave a lovely presentation on how narrative and storytelling immerse players. His new game looks gorgeous.
My talk was on building an application that rescued princesses. The goal was to give interaction designers some insight into how game design might be applied to the domain of more utilitarian applications. The talk was recorded and should be up sometime this week. When it appears online, I'll link to the video from this post.
Here are my slides both in PDF format and as the original PowerPoint.
The notes fields are heavily annotated with more details about each visual. For those of you who attended, this deck also includes a third section on game design patterns that I didn't have time to cover in the time allotted.
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.
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.
The Nintendo Wii has an inexplicably complex help system. A cat wanders onto the screen periodically. If you move your cursor quickly towards the cat, he'll run away. However, if you are careful, you can sneak your cursor up on the cat, your cursor will turn into a hand and you can grab him. When you do, you get a tip about how to use the Wii dashboard.
From a simple efficiency driven point of view, this is a baroque UI that makes very little sense. Surely, just putting up a hint button that says "hint!" would have been more efficient and discoverable. This is what most programs do.
Yet, we know from long experience that no one ever reads the hints. Designers often resort to placing the hint dialog at the startup of the application so that the user is forced to jump through the hoop of reading one hint every time. Most people immediately turn this 'feature' off after using it once. Some users find it highly irritating and form the opinion that the developer is punishing them for using the product. They complain to their friends and write pissy rants to the help desk about why your product is horribly difficult to use. This is not the way to build a viral buzz.
The Help Cat uses traditional game mechanics to help acclimate the first time Wii user to the new controller and the dashboard. In the process, it provides an interesting test case on how game mechanics can be used help users master new functionality.
Analysis I've broken down the Help Cat user experience in several levels of mastery. At each level, you'll see the user happen upon new information and adapt their behavior accordingly. I'm using my atomic game mechanics system from a previous post as a framework for identifying the various steps in the process.
This admittedly gets a tad anal retentive, but bear with me. It is a good exercise in analyzing a user interaction and understanding what works and where it can be improved.
Level 1: Passive interaction
Action: User looks at screen for X amount of time
Blackbox: Cat simulation runs
Feedback: A cat walks onto the screen.
Mastery: The user realizes it is a cat and activates their known tools for interacting with the cat. There is a small burst of delight often in the form of "Holy duck boot! It's a cat"
Level 2: Active interaction
Action: The user moves their cursor in the direction of the cat
Blackbox: Cat simulation runs
Feedback: The cat runs away from the cursor.
Mastery: Wow! It acts a lot like a cat. The user becomes aware that the speed and location of their cursor is important to interacting with the cat and begins consciously practicing mastery of these basic tools. They form an initial mental model of how the cat behaves. This too is delightful.
Level 3: Improving skills At this point the user is engaged and will often attempt to experimentally validate their mental model.
Action: The user begins varying the speed at which they approach the cat. This quickly become a case of seeing how close they can get to the cat before it runs away.
Blackbox: Cat simulation runs
Feedback: The cat runs away from the hand. However, if the cursor touches the cat it turns into a hand.
Mastery: The user has accidentally stumbled upon a new clue. The hand again is a symbol that taps into pre-existing conceptual tools. The user understands that they can use the hand to grab objects. This also ties into their knowledge that cats are an object you can pick up. A new goal suggests itself and there is a small burst of delight.
Level 4: Completion Experimentation continues with the goal now being to catch the cat.
Action: The user exercises the tools from the previous stages of mastery. They move the cursor at the right speed towards the cat and attempt to get the hand to appear. They test out their new model of how the hand works by clicking frantically on the cat. .
Blackbox: Cat simulation runs
Feedback: When you successfully click on the cat, the help box appears
Mastery: The user realizes the purpose behind the cat. There is a large burst of joy as all the clues finally click into place and the pattern of clicking on the cat to get help is chunked in the player's mind. They read the tip and realize that there are likely more tips if they catch the cat again.
Benefits of the Help Cat We end up with a variety of benefits from this less efficient, but more enjoyable interaction design. Each of these benefits goes beyond utilitarian expectations of a traditional hint feature.
Users actively attempts to 'collect' help tips. The process of gathering them is enjoyable so it isn't really work to learn more about the product.
Users also build critical skills in using the new control mechanism. All that pointing and clicking builds up muscle memory skills that make the process of using the Wii more enjoyable overall.
Lastly, the user is left with a positive product experience. They are delighted and are much more likely to promote the product to their friends.
Future improvements As far as it goes, the help cat is pretty nifty. However, the help cat was likely added as a minor bonus feature and as such, has limited functionality. It is easy to imagine additional game mechanics that increase the usability, enjoyment and addictiveness of the help system.
Tuning difficulty levels
User achievement tracking
Virtual pet rewards
Tuning difficulty levels Not everyone likes the Help Cat, mostly they can't figure it out. Anytime you create a black box that a percentage of users cannot decipher, you'll often find frustration and irritation. Users who find a problem too difficult will assume that it is broken. Users rarely blame themselves for failure.
For some, the help cat moves too quickly at first. Or perhaps people don't make the leap that they are supposed to click on it. Or they hate cats and couldn't imagine wanting to touch one. Since the help cat leverages existing cognitive tools in order to kickstart the mastery sequence, the limitations of your users can ruin even the most 'intuitive' design.
The fix is to test user response in order to establish typical responses. Tune the difficulty so that you make most people happy and able to master the sequence. Then set up boundary conditions that trigger more explicit instructions for the slower users. For example, if the Help Cat has run away multiple times but the user has not reacted, put up text that says "Click the help cat."
You need to be careful here. If you make the feedback too obvious, users won't experience the joy of mastering the blackbox. User achievement tracking Mastery typically occurs through practice of a gesture. Far too often, users glances through the help and then never actually performs the suggested actions. By tracking new UI gestures as goals and rewarding the user when they complete those goals, you dramatically increase the likelihood that users will experience the full range of the interface's functionality.
Each hint that the Help Cat gives represents an additional skill that for the user to master. As they meander through the rest of the UI, the existences of the goals acts as a strong reminder to try out the skills. The system can detect and record this practice. Every time you visit the help cat, he can give you additional stats on your progress and may even reward you with additional functionality.
A big benefit to this system is that it is completely non-linear. Users don't feel constrained to slog through a linear tutorial. They can cherry pick the new skills that sound interesting. They are also rewarded for personal exploration. If you happen to discovery skills on your own, the help cat will notice and reward you for the completed quests.
A secondary benefit is that once you get achievement tracking in place, you can easily hook it up to a logging system to gain a better understanding of what skills are being mastered and which ones are not. This can lead to more focused usability testing that improves your overall product.
Virtual Pet rewards Catching the cat to get a clue is interesting at first, but users quickly burn out on this simplistic game mechanic. You can improve usability and increase player addiction by making the cat become the user's friend. You can tap into the user's deep set of existing social tools with some well chosen feedback. The result is a strongly positive user experience for very little effort.
With continued usage of the Help Cat, decrease the response time when the cat runs away. Eventually, make it bounce excitedly when it sees your cursor.
When the cursor is over the cat, have the cat purr and rub up against the cursor.
After more use, when the cursor is moved over the cat, trigger various petting animations.
Explicitly reward goal completion with avatar items that appear on the cat and new playful animations.
These are all straight forward mechanics that require little effort to implement. However, they create strong positive feelings in the user. They can tell a little story to their friends of how they tamed the Help Cat and it is now their beloved pet. I wouldn't be surprised if there sprung up Help Cat fan sites in response. Contrast the warm and loving Help Cat to Clippy, an intrusive alien character that forced information on users. If you want the user to master an action, dangling a carrot (or in this case, a cute fuzzy cat) works much better than a hitting the user with a stick.
From a game design point of view, what we've done is cap the user's advancement along the mastery curve with an 'unwinnable' social mechanism. Such evergreen rewards like a purring cat have a much lower chance of burnout than internal rewards based off points and goals. We can only afford to put a limited amount of content into a mastery sequence, but we don't want to leave the user feeling that they've expended all this effort only to reach a meaningless dead end.
The other benefit of this mechanic is that the Help Cat becomes easier to use. Instead of chasing it around the screen, you simply click on it.
Closing thoughts The Help Cat is a simple interaction design, but it brings out a universally applicable pattern of user behavior
The user performs an action
While performing an action, they stumble upon evidence that a modification of their behavior may have better results. At this point, they experience joy.
The cycle repeats
We can design explicitly for this learning cycle through careful placement of feedback and tracking of user progress. Users learn the product more quickly and they are rewarded with a continuous stream of positive feedback.
I've been thinking lately about how game design applies to the broader topic of software development. Game design is all about creating pleasurable learning experiences and mastery of conceptual tools. Surely more traditional software could benefit from the design wisdom and theory that we've built up over the years in the game industry.
The current state of the art technique for user experience design is the scenario-driven development. It isn't all that good at creating pleasurable software, but it provides a good foundation for the discussion. Scenario-driven design typically involves the following activities:
Create a list of common user tasks called scenarios.
The development team builds a set of features that enable the user to complete those tasks.
You can then run some representative users through the scenarios to see if they can use the features to complete the tasks. If not, you improve your UI. If the tasks are readily completed, then you have a competent product.
This is a big improvement over the older practice of feature-driven development, where developers build the features that they desire and then pray that the users will like them. Well executed scenario- driven development results in eminently functional software from which most major annoyances have been stripped away.
It is not a perfect methodology. A good example of scenario-driven development’s failings is the much maligned wizard. By laying out the tasks of a scenario in a linear order, you satisfy all the constraints of traditional user experience testing. A wizard is easily testable, has great completion rates and is highly intuitive for new users. It also happens to be dreadfully dull, painful for advanced users and quite ill suited to taking on tasks outside the defined scenario.
There are three important questions that scenario-driven design has difficulty answering
How to you build a fun experience? Scenario driven design has no concept of user pleasure. It looks for problems to be solved, not pleasure to be given. Yet users obviously react strongly to the sheen on the buttons in OS X. Emotionally evocative feedback matters.
How do you deal with the issue of mastery? In the scenario driven world, the ideal program has no learning curve. Yet expert users obviously exist and they can perform miracles with the right tool.
How do you deal with the issue of flexibility? Scenario driven design is only as good as the scenarios you consider. Especially in a product where expert use occurs, there will be new scenarios acted out by users that you could never imagine.
Borrowing some lessons from game design Mastery-driven design is a refinement of pure scenario model that borrows heavily from modern game design. It brings into play two concepts:
There is a learning curve on every piece of software. This can be a source of great user pleasure and is a critical part of bringing new users onboard.
As the user progresses along the learning curve, they master a set of conceptual tools that can be used to efficiently solve tasks.
Mastery-driven design goes something like this:
Scenario creation: You start out with a list of projected user scenarios as before.
Tool definition: The development team prototypes a set of tools that the user will need to complete the scenarios. Each tool performs a set of useful actions. A next button might take you to the next page. A pen tool might allow you to draw a complicated line on the screen.
Feedback systems: For each tool, the team creates feedback systems in the form of rewards and punishment to encourage rapid and pleasurable user progress towards tool mastery. These are essentially the atomic game mechanics that I’ve described in an earlier essay.
Task completion tracking: Testing tracks the traditional task completion.
Mastery tracking: In addition to tracking task completion, testing tracks tool mastery. In order for a product to be considered complete, users must not only complete the task, but they must demonstrate mastery of the toolset. For example, after a user has used the pen tool once, they are given a different test with the pen tool. In such a mastery test, it is expected that they should complete that task in 1/10th the time due to their expert knowledge of the tool. With such tests, you can gain information on which tools are easily mastered and which tools are not. By testing the same tools across a variety of skill levels and scenarios, you build flexibility into your toolset.
Pleasure tracking: User pleasure in the learning activities is measured as well. You can survey users after each scenario and you can watch for their pleasure and pain during the tests. You can also track dropout rates by finding out when people stop using the tool and at what levels of mastery.
Once you’ve performed these steps, you record your feedback, figure out where you can improve on the various metrics and run through the cycle again. Over several iterations, you’ll converge on a product that is easy and enjoyable to learn and that provides great efficiency and flexibility to expert users. You also generate user lock in since newly learned skills are difficult to transfer. A dash of theory It is common to hear the term 'intuitive interfaces' bandied about, unfortunately with very little understanding of what it means. Often the popular interpretation of 'intuitive' results in a reductionist approach that serves the lowest common denominator. By bringing the concept of mastery into the picture, we gain a much stronger understanding of why one person may find a design perfect, another may find it complex and a third might find it insulting.
Intuition is something you can build in your users: What we consider an intuitive design is typically a design that leverages years of learned behavior and funnels it toward a new use. Humans live to grok new conceptual tools and then use that knowledge subconsciously to solve new problems. As interaction designers, explicitly tapping into this learning process helps us make better software. No only can we tap into users existing learned behavior, we can actively train users to see our software as intuitive.
Why mastery matters to interaction design: Most of the highly effective interaction design we use today has a strong component of mastery. Typing, for example, requires months, if not years of learning before users become competent experts. Yet, it has become a foundational toolset that makes almost every software task around more efficient. If we avoid the creation of tools that require mastery, we immediately filter out some of the most potent and effective designs. To compete with powerful features that dramatically improve your users' lives, you'll need to create tools that require mastery. Least common denominator design isn't enough.
Mastery is an opportunity, not a barrier: The traditional barrier to selling tools that require mastery is that when people don’t know how to use a tool, they’ll often give up on the product completely. The solution is to build the process of mastery into our product designs. as if it were a game. By providing hints, rewards, goals and other elements taking from game design, we can rapidly build mastery in our users. There exists a rich set of game design techniques beginning with rapid prototyping and including play testing, design testing and more
There is a surprising side effect to incorporating learning into interaction design. The initial user experience actually becomes more enjoyable. Our brains are flooded with a wash of pleasure when we grok a useful conceptual tool. By building software that encourages tool mastery through risk/reward feedback mechanism, we can create a mild, but highly effective psychological addiction within new users. We build delight directly into our software. Conclusion Slowly, but surely, we are integrating more of user psychology into the development and design of software. At each stage we’ve added something new.
Stage 1 - Functional Software: How do we make something?
Stage 2 - Utilitarian Software: ‘How do we make something useful and easy to use?
Stage 3 - Pleasurable Software: ‘How do we make enjoyable to learn and powerful for experts?’
It is my deeply held belief that game design will become an important player in all future software development. The lessons it teaches us about pleasure, mastery, feedback and the application conceptual tools to problem solving are applicable across the broadest range of interaction design.
I've been a game designer, pixel artist, painter, tools designer, product manager and marketing guy. I got my first job while in college working on a shooter called Tyrian at a little company called Epic Megagames. These days, I'm designing games deep in the forests of the North West.
I remain, to this day, not a chickadee plucker. Despite the rumors.