Sunday, December 10, 2006

Building fun into your software designs

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.

Food for thought,
Danc.

References
What are game mechanics?
A discussion of a feedback based game mechanics model that is useful in execution of mastery-driven design.
http://lostgarden.com/2006/10/what-are-game-mechanics.html

Games are food for infovores
A brief discussion on how groking results pleasure.
http://lostgarden.com/2006/07/games-are-designer-food-for-infovores.html

Games design mechanics used in common websites
Andrew Chen forwarded me this nice overview of simple game systems applied to popular websites.
http://shufflebrain.com/GDC2006.htm

6 comments:

  1. It certainly is. Can you tell us what program did you use to create it?

    ReplyDelete
  2. I think you have very well explained my recent obsession with the MS Office Beta. Every new feature that I use is a "discovery". I find myself typing things into Word that was just as effectively been written on paper.

    Sadly, It's hard for me to justify the 150+ purchase since I'm no longer a college student.

    ReplyDelete
  3. Never hire a British developer. http://gametruth.wordpress.com/

    ReplyDelete
  4. Interesting... But reading your tool definition I feel that "mastery" comes in to play at the wrong level. In my opinion a tool such as a button or pen should never be complex and require training. They are sort of "atomic tools" and should by defenition be simple. Using different tools together to acheive a more complex goal might require training and a certain level of mastery though.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete