For some odd reason, I've been chatting more with people that are interested creating web 2.0 applications that borrow substantially from online games. If you see games as a technique for teaching skills and maintaining attention in a pleasurable fashion, I would expect this crossbreeding to only expand in the future.
Why games are interesting to the web Website developers are desperate to have their users enjoy the experience of using the website. If you look at traditional usability and interaction design literature, it says a lot about improving functionality, but almost nothing about making that functionality pleasurable. In the gap there as emerged a faith derived aesthetic where minimalist, highly efficient interfaces are described as the major source of user pleasure. If the only tool in your toolbox measures efficiency, that is what you as a designer value. Regardless of whether or not cold efficiency is what your users value.
Games are interesting to web developers because they demonstrate a rich set of techniques, proven over the course of thousands of projects to keep users heavily engaged. Experience points, in game currencies, mission, player housing, avatar creation, and guilds are some of the meta-game systems that are almost immediately applicable to practically any existing class of application. These keep users around longer, give them an increased sense of community and when used appropriately give them warm fuzzy feelings.
Another area of great interest is that game explicitly deal with the concept of user exploration and the acquisition of new skills. They are experts at giving users the freedom to explore at their own pace while still encouraging the user to master new techniques, tools and skills. At the end of a game of Zelda you've learned hundreds of new techniques and you've enjoyed doing it.
At the end of a few hundred hours of used Digg, you've learned perhaps one or two new techniques. If you are really lucky, you've figured out their commenting system. Modern interaction design has great difficulty with the topic of learning. The current rule of thumb is that users should never be forced to learn any new skills in order to use the application. This greatly limits the scope of potential designs and their ultimate usefulness to expert users. Game techniques, as systems that teach, allow designers to break free from the oppressive assumption that they must only design for the lowest common denominator.
The baggage of games Games also bring with them some interesting baggage. There is an unfortunate tendency to copy wholesale a game design and merely reskin it with a new theme. Math Blasters is certainly not the high point of cross breeding interaction design and game design. We need a deeper understanding of game design that allows us to choose the right elements for the job at hand. Here are a couple of pitfalls.
Don't use spatial relationship if it isn't necessary Most occur in concretely realized spatial environments, whereas most applications do not. You play a game in a world with walls and ledges and characters. Many of the core mechanics of existing genres are built around these constructs. Some designers immediately think "3D world like Second Life!" when they imagine a game-like application. One of my favorite 'horrible user experiences' was in the early days of VRML, some fellow had replaced the desktop with a virtual office you wandered about. You were forced to walk from shelf to shelf and fiddle with clumsy 3D notebooks in the vain hope of finding the right 3D model that represented your last used document.
Applications operate in an abstract land of concepts. The mapping between navigating a maze in Pacman and linking cells in a spreadsheet formula is not obvious, nor is it likely even desirable. Instead consider the dozens of other game design techniques such as point systems, power ups, skill trees, currency and more. There are plenty of useful techniques that don't involve wandering about a world.
Inappropriate use of theme for the application at hand Two people in the past week have asked me, "Does including a rich game-like theme increase the number of users or scare them off?" Their worry was that creating a theme for their application that sported rich characters and a predefined world (in one case a fantasy-land and in the other case a soap opera-esque college scene) would create an immediate filter that knocked out a goodly number of people from even trying the app in the first place. If you look at MySpace, Facebook or Digg, none of them have an obvious theme and they are the gold standard of success. Admittedly, almost all web 2.0 projects adhere to a ruthlessly minimalist school of design so that absence of rich setting is by no means evidence that it doesn't work.
Yet, if you were building a game world, this isn't even a question you ask. Our assumption is that people need a theme (Pirates! Elves!) in order to engage the abstract mechanics of the game. The theme is both the initial hook and a way of creating a context for the actions that eases the learning curve. Game designers can point to Warcraft, Tomb Raider, Ultima, and Mario and practically any title except Tetris that setting is critical to success. We fixate on establishing a rich, unique world as the single most valuable element of a game's brand.
But truth be told, I don't know if a rich theme is always a good idea for every application and every audience. Perhaps more importantly, I don't have the analytics tools (beyond some informed guesses) that would provide the insight necessary to make a good decision.
An open field I'll stop now since this is my attempt at shorter post and it is a rather enormous topic. We are in a place where there is obvious benefit to be gained from cross breeding the two worlds of traditional interaction design and game design. However, it is not completely clear what should be borrowed, what should questioned and what should be reinterpreted. It is a fascinating topic for further inquiry. :-)
What is interaction design "Interaction design aims to minimize the learning curve and increase the accuracy and efficiency of task completion, without diminishing the value of a product's useful functionality. The objective is to lead to less frustration, higher productivity, and higher satisfaction for users." - http://en.wikipedia.org/wiki/Interaction_design "Ideally, products would have no learning curve: users would walk up to them for the very first time and achieve instant mastery." - http://www.asktog.com/basics/firstPrinciples.html
All wonderful stuff that I practice daily. What I find fascinating is how there is no direct representation of user pleasure in the process. There is instead an assumption that by solving a problem in a pragmatic fashion, the user will automatically become happy. Taken to an extreme, interaction designers seek to build a utopia where every action is transparent and effortless.
Yet online game designers know from painful practical experience that utopias result in angry, destructive users. In almost all game designs, the process of mastery is the source of user value. An acknowledgment of pleasure of doing is missing from modern interaction design.
PS: July 2nd, 2007: Updated post to clarify the structure a bit.
I just got out of the packed keynote for MIX 07 in the surreal universe that is Las Vegas. The event was set in an enormous hall at the Venetian with four cinema sized screens dominating the stage. You could see individual pores on each speaker. A band on raised stage was rocking out to sweet accordion music set to what appears to be lyrics about pickles. All around me are masses of developers, designers and Microsoft folks gabbing about art, Macs and revolutionary new technologies. Wait, where was the chatter about black helicopters and the joys of pragmatic Outlook maintenance? Cultural dissonance rocks my world.
The big news of the event is that Silverlight will have will have full .NET support. Silverlight, for those who haven’t been following the glorious web technology soap opera, is a cute little browser plug-in that allows you to build rich internet applications. I think technologies like this are good for game developers. More on that in a bit.
Expression Design is released My product, Expression Design also went live Monday morning and I picked up a boxed copy at the event. To say the release process is like giving birth is perhaps extreme, but I’m very proud of my team. They’ve waded through swamps of vipers to get this product out the door and are already rearing to work on the next version.
Version 1.0 graphics tool are rather rare and mysterious creatures that few software developers get a chance to work on. I’ve been blessed with the opportunity to design three in my career and have come to realize that their promise is greatest even when their features are most limited. The next few years will be a rush.
SpaceCute supports Silverlight If anyone is interested in dabbling with either Silverlight or Expression Design, it just so happens that all the SpaceCute graphics were built with these technologies in mind. To squeeze the delightful XAML marrow out of the SpaceCute files just follow the steps below:
Import the .design file in the zip into Expression Design
Click File > Export in the menu.
Select XAML as your file export type
Voila, you have a lovely chunk of XAML assets for messing about with Silverlight. You can now make a sexy, zippy, web-based version of SpaceCute that runs on both the Mac and the PC in Firefox or Internet Explorer. Here are links to all the files.
Why web-based technologies are desirable for games I’ve devoted most of my professional life to making complex game technologies more approachable and accessible for creative people. Silverlight and Expression Design are just a couple more steps along that path. I’m a big fan of runtime technologies like Flash and Silverlight because they offer two important advantages to small game developers.
Simple install: A massive percentage of (often upwards of 50%) downloads never make it onto the customer’s machine. That translates directly into lost sales for those starving indies of the world. A single click install where the player has instant access to your game allows you to capture player interest immediately. Once you’ve hooked them, you can stream in additional levels, cut scenes etc at your leisure. When you increase your initial conversion rate, you increase your revenue. It is simple math, but a bloody hard technological problem to solve well.
Reliability: Custom engines run well on the developer’s machine, but often fail in horrendous ways on a multitude of customer configurations. A mass market runtime backed by a company whose biggest value proposition is a great experience on the widest number of machines means you shouldn’t have to worry. The number of support calls a Flash developer fields regarding video drivers crashing their customers computers is substantially lower than the number fielded by folks who build a custom engine.
Areas for improvement Obviously, not all game developers use Flash or Silverlight. If you look at top titles like Bejeweled, Peggle, or Aveyond they still use old school downloadable installers. In the past few years, there have been big obstacles to using browsers plugins as your primary platform for casual and indie game development. The good news is that these problems are slowly, but steadily being eradicated.
This is the area that Silverlight addresses. The addition of a full-fledged language like C# should not be underestimated. You’ll start seeing more complex games with more intricate behavior. You’ll be able to easily create scalable, robust architectures using familiar tools. This advances us beyond ‘house of cards’ applications and opens up rich clients to the classically trained master programmers of the world. I am a great believer in their creative powers to blow our minds and change the rules of the game in the process.
Speed: Traditionally, web-based engines have been slow. Users are subjected to slow framerates, small number of objects on the screen and wimpy dynamics. It is not really surprising, given these limitations, that the majority of Flash games are simple action games or point and click adventures. Our runtime technology is barely capable of running games that were popular in the early days of DOS. With technology limitations, come genre limitations.
Local storage: The biggest reason that folks are using downloadable applications is that many users still play offline. Ideally, we could cache 20 megs of data plus a 2 meg save game file on your hard drive and allow you to use the application when the internet is disconnected. This is exceedingly difficult with current technology.
Some of the technologies that Adobe is working on looks promising here and I hope to see more from Microsoft in the future. When game developers gain control over their caching and local storage, the silly distinction between online and offline starts to disappear. This blocker hasn’t been solved yet, but there is hope.
Future of mixed cloud/client games What really excites me is the mixed world of applications that sit halfway in the cloud and halfway on the client. As these become easier to develop, more people will get into the market and they will innovate in order to differentiate their products. Casual game developers are just starting to dip their toes into this universe, but with time expect a flood of interest. Occasional connectivity + instant downloads is a huge and exciting opportunity to create entirely new genres.
Shared user created content: As users create content and upload it to a universal cloud, you open the world of massively single player games. Imagine Spore as a web-based RPG or platformer with a single click install.
Multiplayer experiences: Little Big World shows a little bit of what can happen when you mix an traditional platformer with online capabilities. Imagine if most web-games had this level of multi-player mechanics.
New revenue models: The retail model of paying 19.95 for a mess of levels is due for a shakeup. Micropayments in casual games are a natural fit for cloud/client games. The cloud provides the persistence and the payment system. The client provides the rich interactivity that captures the player and provides the compelling context necessary to encourage them to invest monetarily in the game.
Stats: Great games are well-balanced games. Well-balanced games are created through the massive amounts of user feedback. Internet enabled games offer a natural way of collecting copious amounts of player data in a transparent manner. Imagine if all games had Valve-level diagnostics built in. If websites can do it, so can games.
Ending thoughts I’m excited about Silverlight, not necessarily because it solves all the problems facing game developer or because it provides all the solutions. I’m excited because it adds a serious jolt of competition that is bound to drive rapid advancements. The improved tools and more robust runtime platforms that result from competition are huge wins for game developers. They allow us to focus on making great immersive games, not on rewriting our game engines for the 57th time.
For at least the next five years, the casual and indie games marketplace is going to be a crazy ride. The ‘typical’ genres of point and click Flash adventures, shooters and downloadable Bejeweled clones is going to replaced by instant install, rich applications that cover a much broader range of game genres. Developers will have the power. They just need to use it to make something amazing.
I just came across an article by the good folks at Introversion discussing procedural animation and its benefits versus hand crafted content. Some of my favorite games of all time are riddled with procedural content. The universes of Elite, the dungeons of NetHack, the random maps of Age of Wonders...all these are littered with procedural content. And how could I forget Dice Wars. Or Tetris. Or Poker. The more handcrafted content you build, the more it costs. There are few economies of scale. Want a new level? Add a couple more monkey designers and artists to the team. Want a higher level of detail? Add some more team members. Procedural content has the benefit that despite an initial start up costs, you get immense amounts of content for little to no incremental cost. Procedural content also is inherently more agile friendly than handcrafted content. It can be refactored, unit tested and evolved in an iterative process that lets you try out new ideas quickly.
The problem with hand crafted throwaway content If we look at content from a rewards perspective, you can classify content in games into two main buckets:
Throwaway: This is content that the player sees once or twice and then proceeds to ignore every time they see it again. It has a very high burnout rate since the player immediately sucks any value from it, groks it and then filters it out as noise. In order to keep throwaway content exciting, teams produce large amounts of it and direct a steady stream of empty calories at the player. RPG's, Adventure games and many single player FPS have mastered this technique. Most plot points, level designs, conversations with towns folk, etc fall into the throwaway content category.
Reusable: This is content that the player keeps coming back to again and again because it tends to be useful. A new character with abilities, a new weapon that has a unique effect on the environment, a store that lets you trade in resources are all examples of reusable content.
Handcrafted content is expensive in bulk, but it has another issue: it is incredibly difficult modify quickly. If you build a clown and then decide that a rapid zombie dog works later, you are forced to rework the models and animations completely from the ground up. You can lose month when you decide to alter your static content. Great game play comes about through rapid cycles of prototyping and playtesting. Visuals, settings and level design are feedback mechanisms like any other and need to be adjusted and iterated upon just as much as the algorithmic simulation underneath.
The more handcrafted, throwaway content that you have, the less agile your development process will be. This dramatically increases the chance that you will fail to converge upon enjoyable gameplay. It also dramatically increases the chance that you'll fall back on conservative game mechanics because the act of trying something new is too bloody expensive.
If you are on a budget, you should start identifying throwaway content and figuring out ways to remove it from your design. It may seem like a great idea to have a clown appear in a scripted scene where he describes his life story. However the incremental value to the customer is rarely worth the cost of production or the loss of project agility. Using procedural content to replace throwaway content There are two faces to procedural content. The first is as a hack for throwaway content. It allows you to cheaply replace large amounts handcrafted seemingly meaningful, but actually useless game content with algorithmically generated seemingly meaningful, but actually useless game content.
Is this content critical to a working game mechanic? Identify the feedback that it gives the user and think about how it might provide them with utility. Sometimes you can cut content immediately from the game.
After the user has seen this once, will they ever care about it again? This helps you understand if you are dealing with throwaway content or something meaningful to the player.
If not, is there an inexpensive stylistic tweak that allows me to use a cheaper means of producing the content? If so, there are numerous possibilities here ranging from a less expensive art style, to procedural content, to player generated content. Pick the one that provides the player with the most utility, costs the least and leaves you in a position of greatest agility.
You'll find a lot of procedural content generation techniques that fit the bill. These are rarely up to par with the best hand crafted assets, but they will work in a pinch often at a much lower cost.
Procedural character animation
Using procedural content to augment reusable content The second face of procedural content is where it is integral to a reusable game mechanic. In NetHack, the act of exploring the dungeons and coming across different configurations of monsters and items is crucial to the player's slow but steady unraveling of the immensely complex system underlying the game. Each level was somewhat disposable, but the map generation system was actually an intricately balanced algorithmic method of putting the player in unique initial conditions that helped maximize their learning of new skills.
In a card game, the randomness of shuffling the deck and dealing the players an interesting distribution of cards has a big impact on the gameplay that follows. You simply could not play the game without this element of algorithmic level design. Players would figure out the predictable set of hands and all challenge would be removed.
When dealing with reusable game mechanics, procedural content can replace handcrafted content in the following ways:
Setting up interesting initial conditions, especially with configurations of existing game tokens.
Introducing risk and uncertainty into game mechanics
Where procedural content fails Procedural content is by no means a panacea.
Procedural content is bad at setting goals: Dynamically generated quests were all the rage at one point. It turns out that people just zip through the text. Players quick discern the pattern and you are left with another high burnout game mechanic lying on the trash heap. Good goals are interesting because they are unique; they promise a brand new opportunity learn, advance or help out. They tend to play upon complex concepts of duty, heroism or desire. If you break down why 'Rescue Princess Peach' is meaningful, you'll have a tome on basic human psychology. These are areas where our algorithms are childishly primitive.
Procedural content is bad at most social factors: In fact, you can generalize the concept to say that procedural concept is miserable at replacing most human aspects of content. Conversations, voice acting, descriptions of long lost cultures, plot, all these are difficult to replace. You can either cut them from your game, turn them into easily refactorable modules (like the descriptions in NetHack) or as a very last resort, use traditional, expensive handcrafted production techniques.
Density: Developers sometimes react to the ability to generate infinite levels by building games that sport infinite levels. This is a very bad idea. When you are using a random map generator to put the player in interesting situations, the key operative word here is 'interesting'. All the standard rules of pacing, flow and burnout still apply. If your procedural content only amuses players for 15 minutes, make a 15 minute game. Otherwise start increasing the density of interesting interactions. No one wants to wander for hours through an infinite maze that has no purpose.
Procedural content requires a programmer-designer or programmer-artist: This shouldn't be surprising, but you really need someone who is both a good programmer and a good game designer to make procedural content work. Someone who only programs or only draws seem to be a dime a dozen, but good programmers with design skills or art skills are rather rare. If you aren't such a magic person, so you need to form a team that has all the skills you need. Sit your designer and programmer next to one another and iterate like mad.
Ze sum uppery The phrase "Content is Bad" is of course hyperbolic. To rephrase it, too much handcrafted throw away content is expensive and decreases the teams agility. Procedural content is one solution, but if there is anything I'd take away from this essay, it is the broader concept of creating agile, refactorable content.
If you are smart, your design will change dramatically over the course of development. You'll discover a hundred little tweaks that end up making your final game far better than the initial design. Always be on the lookout for content that you can refactor in some way so that you can change it more cheaply.
Procedural content, when properly used, can turn the bulk of hand crafted content into code with all the added benefits of flexibility and cost reduction. You'll still have a bit left over in the form of variables and other compact data, but this will be much easier to manage.
User created content (which is at least another essay or two) offloads handcrafted content to your users.
If all else fails, at least modularize your content into tiny bite sized pieces that can be added or removed without derailing the ability to do frequent, completely playable builds.
Always maintain the ability to make a change to game play and test it with users within the next hour. If content becomes a barrier to this goal, you need to refactor your content-based systems. Be brutal in enforcing this rule, no matter how much you like that cutscene with the clown. It could save your team and your game.
The plague of handcrafted content is only going to get worse in the future. A friend mentioned that a level in his previous game took 2 days to assemble. Now, with the advance in customer expectations, it takes their team two months to build a level. If it costs that much to build a level from scratch, think of the pain involved in propagating a substantial late game design change throughout a series of levels. I can't help but wonder what their production schedule might have looked like if instead they had adopted the philosophy that "Content is bad."
take care Danc.
"Procedural technique is another name for tool." Jason Booth has a wonderful essay that talk about how much of what we call procedural content is really just another name for tools. They leverage a small bit of creative content to create a lot of gameplay, but they still need to be used in a creative fashion. There is no magic 'make me a world button' and the folks that take this attitude tend to give the whole concept a bad name. http://jbooth.blogspot.com/2007/02/procedural-content.html A more comprehensive definition http://en.wikipedia.org/wiki/Procedural_generation
Thought experiment: Tiles as an early form of procedural content "But most games that use procedural content suck" I recommend folks look at games like Zelda or Mario Brothers. Tiles were a huge innovation that allowed the developer to convey complex concepts (like walls, doors, tapestries, rocks, etc) without drawing ever single scene by hand. Instead you create a few modular pieces and then arrange the initial conditions of those pieces in an interesting way. You only use a small core of handcrafted seed data to build some truly enormous worlds.
This may seem like 'not true procedural generation', but compare it to the other popular alternative of the day: Drawing out every screen by hand. The genre that relied upon this technique, graphic adventures, was pushed into niche status. It simply could not compete economically with the richly interactive environments and economic efficiency of procedural techniques like tile-based environments. Food for thought. http://www.tonypa.pri.ee/tbw/tut00.html
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.
A thousand little decisions go into the creation of a great product. Most are not in the specs or master plans. Instead, they are implemented by testers and programmers. Yet, these are the same people that are traditionally lampooned as geeky and out of touch with the target customers.
What would happen if the developers possessed a deep understanding of their customers needs and desires? Suddenly, those thousand little decisions aren’t introducing random noise into the product. Instead, they are pushing the product forward. A single decision might not make much of a difference, but taken en mass, the momentum generated by enlightened developers can result in a massive reduction in design risk. You’ll develop the right product sooner and with fewer errors.
You can’t unfortunately just say “Dude, I looove my customers” and expect to get results. To harness the power of the passionate developer, you need the following pieces in place:
Meaningful customer feedback
Empowered Developers One philosophy is that we need better specs and those damned monkeys need to implement the specs exactly as designed. Better command and control system and more rigorous process is obviously the trick to success. This tends to generate poor results.
Imagine that you are a highly creative individual whose life is reduced to a series of highly detailed checkboxes that you are told to fill out one after another, day after day. If you deviate, you are punished and ridiculed. The results are gun-shy, non-communicative production workers that rely on obfuscation and deliberate bending of rules in order to express their innate creativity. Many wonder why they got into this dreary business in the first place. Others just give up.
When indentured coders and testers make design decisions, they lack both the experience and the desire to do the right thing for the user. They’ve been trained to take orders from management instead of building up an intimate empathy with their user. In the best of worlds, they implement uninspired versions of the features described in the specs.
In the worst of situation, they labor in secrecy, adding a little bit of their own uninformed creativity back into the product. When confronted with the havoc wreaked by Byzantine architectures and convoluted, unnecessary features, the humanoid production resources are surprisingly defensive. How can you be angry? They were just trying to salvage a small bit of their creative souls.
Such feature creep is not the fault of the individual testers or programmers. It is the fault of the team and management for turning a creative and invigorating process into menial labor where talented creators have no other option but to rebel.
We need a different philosophy based on passionate, educated team members that put the user at the center of their world.Developers gain the power to make their own decisions through their deep understanding of their customers.
Simple beliefs Empowerment is a word that has been stripped of much of its initial meaning by the hippy liberals of the world, but the concept is rather simple. An empowered person is someone who has the ability to make their own decisions.
Let’s look at some building blocks that need to be in place before you can have empowered developers. You need to believe these are true and the people on the team need to believe that they are true. If these foundational beliefs are weak, it is very likely that you’ll end up falling back on command and control decision making structures in the face of emergencies or pressure.
Developers are passionate people: Even technical people burn inside with an inner flame of intense creativity. It can be hidden. It can be misdirected. But you must believe that it exists. The other insight here is that developers are motivated by very human issues. Dream, fears, respect and social hierarchy have a greater impact on productivity than economic incentives or logical rules.
Most decision should occur at the edges: Management serves a useful role in maintaining group cohesion. They rarely however, have intimate knowledge of the production issues experienced by individual workers. When developers at the edge with customer empathy are encouraged to solve problems that they happen across, a hundred issues that are invisible to managers start going away. A well functioning team is bursting with these small acts of ‘goodness’. Over the course of a project, the momentum results in an order of magnitude improvement in product quality. The most important outcome of this philosophy is that the people who build a piece of customer work flow hold absolute responsibility for it’s usefulness to the customer. “I’m just doing what I was told to do” is the vilest of attitudes.
Encourage learning through failure and feedback: The urge to control production often stems from fear of others making mistakes. “The morons are going to just screw things up!” is a common refrain. If you remove the opportunity for people to make bad decisions, you slide rapidly down the slippery path of command and control. An empowered developer has permission to fail. In fact, rapid, low cost failure is actively encouraged since it is the single best way to learn about how to make the product better.
Customer feedback Now we have a team of passionate people. They are solving problems at the edges and they have permission to fail. Wonderful! We still, however, are missing the most critical element. We need to build a strong customer feedback mechanisms that encourages the team to create a product that matters.
Identify the customer
Believe in the customer
Get close to the customer
Identify the customer Identifying your customer is where an amazing number of teams fail. They become focused on a bit of technology and imagine that users will just appear out of the woodwork. The whole process of iterative product design requires an identified customer so that you can know when you are on the right track and when you need to change direction.
The first step is to write down your customer definition. You’ll take into account market data, economics, opportunities that you’ve noticed and a billion practical details. It will feel like a very intellectual pursuit. The next step is to go out and find an actual, breathing human being who represents your customer. Customers are not data points. They are people that you can question, observe and befriend. The customer definition is just a tool that helps you narrow down your search. The real win is when you can get your customer in the room with your developers and they can drink a beer together. PBR FTW.
This isn’t easy. You may not be able to find a single person who represents your typical customer. You may end up with multiple customers that represent different needs. You may find that people on the team had very different ideas of who the customer might be. You’ll likely redefine your customer multiple times once you start talking with your initial customer prospects.
It is okay if it is hard. Don’t give up. Choosing your customer is the single biggest product design decision that you will make over the course of your entire product’s development. My belief is that no project should be green lighted for even minor development unless the team has had extensive conversations with an identified target customer. Belief in the customer The user of your product must be worthy of great passion. Remember, we are dealing with passionate developers thrive on living meaningful, creative lives. When the target customer is considered unworthy or boring, the development team will feel little urge to empathize or go the extra mile.
Product development is a service to others. The products we produce make someone’s world a better place. The team must be able to explicitly articulate why it is worth spending years of their precious lives providing the target audience with a new bauble. If you can get everyone on the team to passionately proclaim that they wish to serve the customer, you have built a powerful unifying vision that will carry the team through hard times.
It is worth noting that practically any customer can be worthy of great passion. All customers are people with dreams and passions of their own. They have tricky problems that result in very emotional human costs. An important aspect of connecting the passion of the developers with the passion of the customer is to identify the human, emotional aspects of the customer problem and bring those to the attention of the team.
Get close to the customer Once you’ve identified your customer, you need to figure out ways of gathering information about them. One of the great Zen mysteries of product design is that in order to successfully serve your customer is that you should never give them what they request. So you can’t just grab a customer of the street and ask him to design your product. An average customer is good at identifying problems, but they are poor at prioritizing, understanding larger patterns and generating elegant solutions. That is your job. Your customer is there to let you know when you get things right and when you get things wrong.
The feedback cycle is pretty straight forward
Identify a problem or opportunity
Build a valuable solution that fits the available resources constraints.
Present the solution to the customer and record their response. Do they realize the value of your solution?
Use the data to identify new problems and opportunities. Look at the big picture and start the cycle all over again.
There are a plethora of good techniques available for getting closer to the customer. IDEO has their 51 ideation cards, college design courses teach books worth. They operate at different timescales and give you different types of information. Implement multiple ones and see which ones work the best for your particular customers. Here are some of my favorites:
Use your own product: Try to replicate what you see your users doing. Mimic the masters so that you understand their thought process by doing. This builds developer empathy with your customers and is one of quickest feedback cycles around. It also however, can be highly biased.
Onsite customers: Make a customer or two part of the development team. You get very rapid feedback and lots of cultural transfer into the team. The downside is that customer objectivity can be polluted by constant contact with the team.
Observe customers using your product: Set up usability studies and gather both quantitative and qualitative data. Every team should do this, but it can be expensive and feedback only happens in spurts.
Hire psychologists and ethnologists to study your customers: You’ll often gather key insights that would otherwise slip by someone not trained in methodical observation. Making these results actionable often takes additional work.
Listen to lead users: Some users are actively solving the same big problems that you are attempting to solve, often years ahead of the market. Find them and learn from their successes and failures.
You are always balancing three different aspects of the customer feedback.
Reduce feedback cycle time: The more quickly you can fail, the less effort you can put into each failure and the sooner your can correct your course
Improve objectivity of results: It is easy to get biased results. Many of the issues dealing with customer psychology are fuzzy in the best of situations and the developer’s own interpretations often dramatically skew the data.
Improve clarity of results: With more data comes more noise. Boiling down the flood of information into actionable, meaningful results that the team can understand is an ongoing activity. Many teams collect customer information, put it in a binder and then never look at it again. If you don’t act upon the customer feedback, it isn’t useful.
There is a substantial cost to all of these activities. You’ll need to change your development practices. Daily builds and regular check-ins help ensure that you always have a product that your can put in front of users. You’ll need to spend money. Bringing in users, ethnologists and usability experts adds to your headcount. This is the cost of doing business. Barriers I’ve laid out two pieces of a successful product design team. The first is empowered passionate developers and the second great user feedback. Without the first, user feedback is either ignored or fails to permeate the multitude of small decisions that go into building the product. Without the second, the team spirals off into wasteful directionless exploration.
The single biggest barrier to creating a team of developers that are passionate about their customers is the core cultural beliefs of the people already on your team. Chances are good that they rose to where they are today by mastering a traditional command and control style system. They’ve been personally rewarded throughout the years by checking off the check list or writing checklist for others. They got a big fat raise for staying late and adding those 12 new features from the spec. When the product fails, they are told, “We should have added those 6 more features that got cut because developers were so slow.” The weak ones leave and the ones that are great at silently adding questionable features are promoted and promoted again. They are trained, their egos are invested. After five to 10 years of this, an experienced developer builds up an unshakable, unquestioned belief in command and control style development that only falters when they finally die off.
A thousand little successes do not start with a mandated policy. They begin to gain momentum when the role models within the company start acting upon the beliefs in concrete ways. This is where most process change breaks down. People say one thing, but revert back to habitual behavior when the going gets tough. They still believe, deep down, that the old method of command and control is less risky than trusting a team driven by passion and customer feedback.
Only when people on the team have personally experienced success using the new techniques and they’ve adopted new beliefs as a core of their personal philosophy will momentum sweep through the entire team. Several items need to be in place:
The right people: You need a core group of people willing to believe in both developers and customers. These folks are rare since the current system isn’t focused on producing them. If you find one, hire him or her immediately. The culture they bring to the team is worth as much as their skills alone.
The right situation: Often people need to be in the middle of a failing project before they will consider that there might be alternatives.
Time: Smart, strong people do not give up their culture overnight. After years of steady and obvious success, they’ll start to shift. Start with a like-minded core and grow it slowly.
Very few companies have all these items align. I was chatting with one insanely successful game company that follows many of these methods. They’ve given talks on their process. They’ve partnered with other companies and attempted to teach their process. Each time it fails. Imagine a company that consistently releases highly profitable AAA titles merrily giving you their secret formula. Would you take it?
Yet no one does. It would require companies giving up their most fundamental beliefs about how software is designed and built. They would need to give control to the lowest people in the organization, embrace a constant stream of failure and put customers, not their creative urges, at the center of the design process. That, my friend, is scary. Product success is cool, but a shot a being Top Monkey in the current ineffective system is much more attractive.
Why are we in this business again? Where is our urge to build great and wonderful things that serve the world? It seems a shame to let tradition, habit and hierarchy get in the way.
Conclusion Lately I’ve been contemplating a nuclear bomb of a statistic. 80% of software features are either never used or used very rarely by customers. Anyone who does software development should be staring at that number in shock. 80% of your sweat and tears has little to no customer value. In most cases, customers would be just as happy if you were to give them 1/5th of the existing product and make that little sliver work better. How much time and resources could you save if you only delivered the right features?
This in turn has gotten me thinking about the common software development practices, the ones that fixate on execution risk instead of design risk. What we build is just as important as the fact that we can crap out a product by Christmas.
Passionate developers that empathize and listen to feedback from customers form the foundation of an efficient team for one central reason: They are very good at reducing the risk of building the wrong product.
Team members more readily identify areas of design risk that require iteration with customers.
Any big design mistakes are caught early through customer feedback.
Small decisions are made more rapidly with fewer errors.
You aren’t going to save 80% of your development time since all this iterating does chew up a serious effort. But you may save 50% or 60% of the budget. More importantly, you may end up releasing a product that is of value to someone that you care deeply about.
Software Development's Evolution towards Product Design
Occasionally, some poor fellow at a dinner party makes the unfortunate mistake of asking what I do for a living. My initial (and quite subdued) response is that I help design software for artists.
Then comes the inevitable question, “Oh, so you are a programmer?” A gleam appears in my eye and I no longer feel obligated to blather on about the rainy weather. With a great flourish, I whip out my gold nibbed pen and draw a little diagram on a napkin that explains concisely how modern software development works. In the grand finale, I circle one of the little scribbles buried deep in the entire convoluted process and proudly proclaim ‘And that is what I do!”. This admittedly selfish exercise usually keeps everyone involved merrily entertained until dessert arrives.
After dozens of napkin defiling lectures, I’ve put together an extended PDF of my sketch for download. In short, we have a one page infographic that explains:
The evolution of software development over four distinct eras.
The key goals of software development and our saddest failures
Where software development is moving in the future.
The diagram also contains a surprising amount of poo. But then, that is the bigger lesson lurking within the scrawls. Much of what software developers create fails to serve the full spectrum of their customer’s needs. The funny part is that the usually non-technical folks that I’m talking to laugh heartily at this point…they know exactly what I’m talking about.
You can download the full PDF here. Print it, share it with your friends. Read on to hear how we got to this point. The Technocrat Era: Programmers serving programmers
At the dawn of software history, programmers wrote software for other programmers. This was a golden era. Life was so simple. The programmers understood their own technical needs quite intimately and were able to produce software that served those needs. The act of software development was a closed circuit. A programmer could sit in a corner and write code that he wanted. By default it also happened to apply to other programmers.
Programmers that grew up in these idyllic days still remember it fondly. There is still the programmer who will claim that all they need is EMACS and the latest version of GCC to make great software. For software intended for a highly technical audience, they may well be right.
The Early Business Era: Programmers attempt to serve others
The end of the Technocrat era was came about due to a startling discovery: the vast majority of the world was composed of non-technical people. Artists, accountants, authors, history majors and other unexpected consumers roamed the prehistoric landscape outside the hallowed engineering halls.
A new class of software entrepreneur called a ‘business man’ came into existence. This new creature realized that the hordes of non-technical people had their own needs that might be served by a well written program running on one of these new fangled “personal computers.” The business man gathered programmers and told them to build software to solve things like balancing budgets or writing letters.
The software products that the programmers created were technical marvels. They provided practical benefits far beyond what was available. VisiCalc revolutionized finance. WordStar and WordPerfect forever changed the act of writing. Even the Quantel Paintbox changed the world of art.
And yet the recently converted users, who couldn’t live without the efficient, powerful and technically amazing new software, were curiously ambivalent. They liked what these new products did from a practical standpoint, but found them to be confusing and often quite irritating.
You see, the programmers treated their customers just like programmers. They made them memorize crazy expert keyboard conventions and loaded the product with dozens of obscure features. This is what the programmers wanted out of a piece of software, so they assumed that the customers must want the same.
Unfortunately, the customer needs were a different beast. Their needs could be roughly divided into two categories:
Practical needs: They wanted a product that worked. For example, the product obviously needed to save time and money.
Emotional needs: They also wanted products the possessed less tangible benefits. They wanted applications that treated them with kindness and understanding if they made a mistake. They even wanted to use products that were attractive and conferred status. The customers desired programs that appealed to the softer aspects of their humanity.
When emotional needs were raised, the programmers quickly determined that the customers were indeed “nuts.” The pure technocrats simply did not possess the broad skill set necessary to comprehend, never mind serve, the customer’s unexpectedly important emotional needs.
The Late Business Era: Programmers and artists meet and do battle
The software market had become quite competitive at this point. Business folks, experienced in the Jedi wisdom of more mature markets, reasoned that perhaps serving emotional needs could give their companies an edge. A few companies experimentally hired non-programmers such as artists, marketing and usability dabblers. I use the term artist quite liberally here since it captures that charming, hand-waving vagueness of all classes of “people people”
Oh, the suffering that resulted. The inevitable culture clash was a bit like unleashing wild dogs upon one another and then watching them sulk afterwards.
None of the freshly introduced team members spoke one another’s language. The artists talked about fluff like color and mood. The marketing people made outrageous requests with zero comprehension about technical feasibility. The programmers were suddenly enslaved by bizarre, conflicting feature demands that they did not understand. “Make it friendlier” translates poorly into C++ code.
Let’s take something as simple as making an interface more appealing.
The artist would whip up a picture sporting rounded corners and more pleasing colors. They’d send it to over to the programmer with a hand scribbled note “Make this.”
The programmer then would either A) State that an infinite number of programmers could never finish such a technical abomination or B) Recreate the image using rectangles and the preexisting color scheme.
Everyone would then rage at one another about their general incompetence.
In these battles for dominance, the winners lost horribly. If the programmers got the upper hand, they produced software that, despite great technical accomplishments, was ugly, difficult to use and no better than currently existing products. If the artists got the upper hand, you ended up with lovely products that didn’t do anything worthwhile.
The best products came from those odd teams that managed to compromise. The technology was clumsy and the emotional benefits of the software shaky. But it was better than the crap that customer had to put up with before. The original Mac OS was a great example of this. Later versions of Windows also managed to address a few emotional needs.
The Product Design Era: Can programmers and artists learn to work together?
The clock of progress has moved forward once again. The competition ratcheted up one more notch, and it appeared evident that companies that fail to master the lessons of the last era would be punished by the customers. Our battle scarred software companies were left looking for a better way.
Obviously, designing for emotional needs in addition to technical needs was a winning evolutionary strategy. In the last era however, mixing multiple potent skill sets together left organizational and cultural wounds that often were difficult to heal.
The companies that survived the influx of designers and marketing folks often relegated the survivors to their own separate silos. Marketing people got one org tree, developers got another. Artists and usability folks in most cases were shoved in random back corners to rot in black despair. Many groups were so busy protecting their domain that it was surprising that software got released at all. Release dates slipped by multiple years as the development talent stagnated is a cesspool of misplaced process.
What was needed was the most dramatic of transformations: A change in the cored development process. What made it difficult is that original culture of technocratic software development would need to evolve to support a broadly humanistic approach to product design.
The lead users of the Product Design Era This change found root, as is the case for most dramatic transitions, from the most unlikely places.
There is a concept in product design known as the ‘lead user’. This is a group of users that solves a difficult program far ahead of the mass market. Often they’ll cobble together their own tools and discover fundamental process and technology issues years in advance of mainstream users.
The old joke about writing Shakespeare with infinite monkeys randomly typing on typewriters got it all wrong. Instead give me a million customers trying to do their job with broken tools and one of them will stumble upon a process that is truly better. By watching the edges of the market place, we gain great insight into the direction that the larger market will take in the future.
The lead users in software development came from several widely divergent areas.
The first was the game industry. Here, small cross functional teams built products focused entirely on serving emotional needs. Due to intense competition and vicious delivery cycles, many teams were forced to innovate far outside the traditional software development methodologies.
The second were companies like Apple that followed curious ‘design’ philosophies more similar to that pursued by consumer good companies than software companies. What do shampoo companies and software development have in common? A remarkable amount it turns out.
The third were web design companies. Due to the low cost of entry and the early emphasis on the web as a marketing medium, the web design market is dominated by tiny, hungry graphic design firms. They brought with them a culture of small teams, close collaboration between artists and programmers, and a nearly slavish devotion to serving their customers.
What the next era looks like Each of these lead users follows a variant of what is broadly known in more mature industries as “product design.” They see software development not as a pure technical exercise. Instead they look at it as an integrative process of building a new product that solves both their customer’s combined emotional and practical needs. Even when forced to use a “technically inferior” platform, the religious devotion to rapidly and effectively serving customer’s complete spectrum of needs make their product offerings more attractive than the competition.
Robert G. Cooper, a well known researcher on new product development, states that there are several core factors  (listed in order of importance) for any successful new product design process:
A unique, superior and differentiated product with good value-for-money for the customer.
A strong market orientation – voice of the customer is built in
Sharp, early, fact-based product definition before product development begins
Solid up-front homework – doing front end activities like market analysis well
Leverage – Where the project builds on business’s technology and marketing competencies
Market attractiveness – size, growth, margins
Quality of the launch effort: well planned, properly resourced
Technological competencies and quality of execution of technology activities.
Many companies in the Late Business era already emphasize a few of these factors. However, there are some differences. Notice how technical competencies are important, but last on the list. Notice also, how that creating a solution to customer needs is first on the list.
Software companies that understand product design tend to pour their efforts into the following activities:
Focus on a unifying team goal built around customer needs. They ensure that the product is always driven by customer needs, not internal whims.
Work together in cross functional teams. They build an organization that encourages the sharing of skills to promote problem solving. They discourage the formation of silos of individual ‘experts’.
Communicate clearly with a process that applies to all team members. They build a commonly followed process includes both fuzzy front end activities like design and production activities like coding. This process forms the language that unifies disparate groups.
Work efficiently with design friendly tools. The team avoids custom coding and ‘tossing it over the fence’ by adopting tools that work on common data format across all skill sets.
Benefits of a product design philosophy The benefits of a product design process are well documented. New products that deliver superior, unique benefits to the customer have a commercial success rate of 98% compared to 18.4% for undifferentiated products. These products reach an outstanding 53.5% market share.
Some of the highlights of a strong product design include:
Create highly competitive products that achieve market dominance.
Save money by focusing on the right features that bring customer value, not low yield ‘nice-to-have’ features.
Create passionate customers that accelerate the spread of your marketing message.
To the losers, the success of their rivals appears miraculous. “How is it that a slow web app can take away market share from our superior desktop application?” they ask in surprise.
The answer will be simple. The successful company identified the correct emotional and practical needs of the customer and poured their efforts into serving those needs. The richer companies - flush with silos of ‘wise’ experts - fought with one another and threw random features at the customer. It is rarely about doing more; it is about grokking customers and doing the small set of correct things necessary to succeed.
Dangers of the Product Design Era As with any process transition, some groups are adopting these techniques slower than others.
Even within game development there are huge swaths of publishers and development teams that are ignorant of techniques used to incorporate market research, concept testing and new-to-the world innovation into their process.
Many web developers still create new products by following their ‘gut’ without clearly identifying their ultimate customer.
Most traditional desktop software developers are just barely escaping the Late Business era of functional silos and warring factions.
Most laggards who hold desperately onto their aging processes will die off in the face of advancing competition. Those with larger war chests merely buy a small period of additional learning time.
Unfortunately, many companies that attempt to adopt a product design philosophy will also fail, despite their best efforts. Cultural change is hard work. To adopt product design you must alter the most basic DNA of the company’s values.
It involves asking vice presidents to give up their empires that they’ve fought decades to establish. What is the point of an organization of engineers when engineers are all just members of small cross-functional teams?
It involves asking the men and women in the trenches to give up their own dreams of building their own empires according to the old rules.
If the ultimate reward of the old system is an isolated corner office with windows, try convincing people to work together in a common war room that has walls covered with whiteboards.
Such traumatic change is absolutely necessary. If you want to make great products for happy customers, you need to make the transition to a broader product design methodology. We may have once been a clique of technocrats. But now we must take our place in the broader society by providing human solutions to the very human customers that we serve.
Dessert After I’m done drawing all this out on my little napkin, I point to one of the designer fellows in a beret and say, “See that guy? That’s me. I work on a team full of crazy, wildly talented people trying to make the world a better place. We make products that you can love, not just products that you use.”
Folks nod. They get it. They like the idea of software that not only works, but makes them feel good about using it. At one meal I was sitting with an older woman who listened most politely to my wildly gesticulating explanation of modern software development.
At the end she said, “Well, it is about time.”
Take care Danc.
PS: This cute little illustration was done in a program I'm busy renovating called Expression Graphic Designer. It will be part of a suite of design friendly tools that seeks to ease the bloodshed between programmers and their more artistic team members. You can't build a cross functional production pipeline without the right tools.
The Apple design team work space “We have assembled a heavenly design team. By keeping the core team small and investing significantly in tools and process we can work with a level of collaboration that seems particularly rare. Our physical environment reflects and enables that collaborative approach. The large open studio and massive sound system support a number of communal design areas. We have little exclusively personal space. In fact, the memory of how we work will endure beyond the products of our work.” – Jonathan Ives http://www.designmuseum.org/design/index.php?id=63
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.