Six lessons from games to bring fun to non-game apps and maximize a positive user experience.
My college roommate was in his nth hour of continuously playing Q*Bert, a cute arcade video game with the object of navigating an adorable creature through each space of a board without falling off the board or meeting up with various dastardly varmints. After a long chain of increasingly challenging boards and amassing a large supply of extra “lives” for his creature, he realized the game difficulty had plateaued. He was at the highest level the machine could go. “I’ve conquered Q*Bert,” he said to himself. It was no longer fun to play. With final satisfaction, he did what he had been trying to avoid doing since he began: he hopped the creature off the board for each of his stored lives, his creature repeatedly plummeting to its doom with a surprised and disappointed sounding, “OOOOOoooooooh!” Thud. After many hours and many quarters, my roommate never played Q*Bert again.
Wouldn’t it be great if our apps could elicit such dedication as Q*Bert did for my roommate? What if instead of learning to navigate a game board, your users learned to navigate your menu hierarchies? Think how much more they would get out of your app. There’s little question that my roommate enjoyed his conquest of Q*Bert. What if your app were as fun? By definition, that would be a superior user experience, and that’s what we want for our users. Or never mind the users, think of your business. Think of all those quarters. If your app were as fun as a video game then users would line up to buy it. Or if it’s a web app you got, you can attract users to your site with fun so you’ll get more traffic doing what your business needs done, such as buying your client’s merchandise or providing content and contacts for your social site. Being fun gives you a competitive edge.
But how…. Should your cursor be a cute creature rather than a nondescript arrow? Should your error messages appear with emotion-laden sound effects of surprise and disappointment? The fun ended for my roommate when the challenge ended. Should you build challenge into your apps so users feel like they’re accomplishing something? If so, does that mean there’s such thing as too much usability -that if you make the app too easy, users will become bored? Or is it okay to trade some usability for fun? Fun is fickle and idiosyncratic. Unlike my roommate, I never developed an interest in Q*Bert even though I tried it too (I was more a Tempest guy). At first it was fun for my roommate to keep the creature on the board, but by the end it was fun to jump off the board. You probably don’t want your users doing counterproductive or destructive behavior like that. For example, you don’t want your social site to be fun for trolls. How do you control fun?
There are lessons we can learn from computer games for making non-game apps, but they may not be the ones you think they are. Simply importing into your app the cute cartoons or challenging situations from games is idol worship, faultily assuming that superficial aspects of games provide the power of fun, rather than learning the deeper truth behind those superficial aspects. We need to dissect fun to effectively bring it into our users’ experiences.
Lesson 1: It’s the Task, not the Tools
We look at games and see that essentially by definition they include challenge, and thus we may infer that challenge is necessary for fun. You conclude that a usable interface is a boring interface, since it removes all challenge. In practice, however, it’s pretty clear that unusable applications are not fun. No one enjoys a challenge in figuring out a UI -not when there’s work to be done. It’s not fun to try to figure out a mass transit trip planner when one is getting late for an appointment. It’s not fun to learn a new menu or “ribbon” for a word processing software when one has a memo to write.
There is a distinction between the task and the tool. The non-game app is a tool to get a task done. An unusable non-game is not going to be fun because that interferes with the users’ task. Perhaps surprisingly, this is true for games too -games need to be usable to be fun. Despite its challenge, Q*Bert had a simple and usable UI: the creature moved in the same direction the user pushed the joystick. If the creature moved opposite of the joystick direction, it would be less fun. Players would have dismissed the game as stupid.
Unusable games are not fun. It’s no more fun to figure out cryptic icons in a game than in a non-game app. Hunting around an adventure scene for interactive artifacts is as annoying as hunting around a web page for what is or isn’t a link. It’s ironic that we’re looking to games to improve the user experience when at the same time game designers are looking to usability to improve their game experiences.
This is because the task/tool distinction applies to games too. The task is the premise and object of the game -navigate the board, engage the zombies, study the mystery, whatever. The tool is the means the game provides the user with accomplishing the task -the console, the menu to select game parameters, the status displays, and so forth. The lesson from games is that fun is in the task not the tools. Users don’t play games to press buttons and navigate menus. They play games to kick major zombie butt.
In games, it’s okay for the task to be challenging. In fact it’s essential for a game to be a game. The only difference between games and non-games is that for games the task is contrived rather than real. For non-games, there is a real appointment the user needs to get to, and there’s a real memo the user has to give to a real human being to read. In games, the race cars, zombies, and dragons are not real. The users accept the game’s reality and its rules, which in effect means pretending that playing the game has real consequences.
Unusable tools make a game less fun because they detract from completing the task. Badly placed buttons on a console make playing frustrating, cryptic menus resulting in incorrect game parameters are annoying. Long intros or splash pages get old quick. A clumsy-steering race car on a screen with slow irregular updates provides poor feedback, separating the user from the virtual road. A pop-up message in the middle of the game suggesting the user upgrade would be infuriating, distracting the user from the task of killing zombies, finding treasure, or getting the little frog safely across the road. In games as in non-games, you want the UI to disappear and leave the user to the task alone. A game can give the user limited ammunition, or hide the treasure in difficult-to-reach places, or have cows wandering onto the race track, because those are all part of the task, not the tools. They are part of the reality the users have immersed themselves in. It’s part of the fun.
For non-game apps, you don’t have to immerse the user in any reality because the user is already in real reality. Well, your users may vary. But speaking for myself, I can say that real reality is already plenty challenging, and you don’t need to be adding any more. Just tell me which friggin’ bus to take, for Pete’s sake, I’m going to be late.
However the lesson from games still applies: if you want your app to be fun, design your UI to make the task fun. Think about how the purpose or object can be fun, not the app. Don’t ask, “What makes word processors fun?” Ask, “What makes writing is fun?” Users have fun when they’re great at the task, not the tool. There is plenty of stimulation, beauty, triumph, and reward in writing that can make it fun. Producing clear creative prose makes writing fun. Words streaming effortlessly from mind to monitor is fun. What can your app do to promote that? For non-games, the fun UI helps with the task challenges.
Lesson 2: It’s the Win, not the Challenge
Okay, so fun is in the task, not the tools. That’s true for games and non-games. Does that mean you should make the task challenging for non-games to be fun?
Really, it isn’t the challenge that’s fun so much as success. Simply put, winning rules and losing sucks. We only enjoy challenges we think we can overcome. Challenges we don’t think we can overcome make us angry, anxious, or depressed, especially challenges with real consequences. Losing is only amusing when there’s no real harm done, when there’s nothing substantial at stake. That is typically the case for games (unless the players are betting non-trivial amounts), but for non-game apps, there is almost always something at stake. The user is trying to accomplish a task for some extrinsic reason. The users may be dealing with time pressure, demands from friends, family, or superiors, and material costs. Start awarding points to users for completing their time sheets at work, and you’ll likely promote more anxiety than enjoyment in your users (“Will the boss come after me, if I’m not a top scorer?”). Add a UI that challenges the users, and you’re likely to get angry, anxious, or depressed users.
Such emotions as anger and anxiety can be motivating, even in games. For example, you might see a player become increasingly frustrated in performing poorly game session after session, but still he returns for more. Maybe poor performance threatens the player’s self-image, compelling him to continue playing until he wins. Whatever the case, it’s clear the player isn’t having fun. If your goal is to promote a positive user experience, rather than just get the user to do something you want them to do, then you don’t necessarily want any challenge in your UI.
So having a challenge doesn’t mean someone is having fun. Furthermore someone having fun doesn’t mean they’re overcoming a challenge. This weekend my wife and I were pulling weeds in the garden, and she said she wanted to borrow a neighbors’ fancy weed-pulling tool because she thought it would be more fun. Why? Because it would be easier. Sometimes less challenge means more fun. Heck, forget the weed-puller. It would be even more fun to wave a magic wand and watch all the weeds shoot out of the ground like ICBMs. That would be a trip. I’d weed my neighbor’s garden if I could do that.
Success, not challenge, is the common denominator of fun, whether it comes easily or not. That all games have challenge is a red herring. It’s a key characteristic of games, not fun. Games must have challenge because without it success at a game has no meaning. You would never make a weeding simulation game featuring a magic wand because waving my virtual wand doesn’t prove I’m skilled or smart, and I still have a backyard garden full of weeds when the game-play is done. Games must have challenge because it really is about how you play the game that counts. Playing well is the goal, however “playing well” is defined. With real weeding, what matters is pulling the real weeds out. A weedless garden is the goal. Assuming your app or web site actually does fulfill some extrinsic useful function for the user, you don’t need to create challenges to make it meaningful to them. It already is. If you find yourself contriving to create challenges for your users in order to “get them to do” something (e.g., hiding prizes to encourage site exploration), then maybe you’re really concerned with business goals, rather than the user experience.
The implications are this: if fun is success and usability brings success, then usability is fun. When the user is using an application for some extrinsic purpose (i.e., it’s not just a game) it should have the best usability possible to be the most fun. You do not want to make the task any more a challenge than it already is. There’s nothing wrong, and nothing un-fun about the task having no challenge at all. The ideal app gives users a regular diet of successes from novices through experts, much like a well-design game does. If you can make a magic wand, make it, and let the user move on to something else to accomplish.
Lesson 3: Boredom is about Frustration, not Simplicity
So you’ve made an app UI that promotes tasks success. You removed the challenges and thus removed the potential for frustration. Congratulations. You now have a user experience that avoids depression, anger, and anxiety. Unfortunately, you now have boredom. Your user experience is tedious, monotonous, and dull. Is there a zero-sum between challenge and boredom? What are tedium, monotony, and dullness anyway?
Excess, pointless stimulation or action is tedious. For example, it’s tedious to read a long blog post that doesn’t really say anything. It can be tedious to sit through a long game intro, not because it has no challenge but because it has no point. Game intros should be just long enough to provide the necessary back story to inform the user of the game’s reality. Once the user gets the gist, the intro needs to get out of way so the user can actually play. You don’t want to make your game users sit through the intro each time they play -that would be pointless, so for a better UX, you should provide users that ability to skip the intro. Users want to get down to business, which means pursuing the game’s objective. That’s the point of the game. Likewise, elaborate realistic 3-D scenes can counter-intuitively make a game tedious because they fail to distinguish between interactive objects and inert decorations added for realism. Certainly hiding the interactive objects in this way adds to the challenge of the game, but it isn’t fun when it’s a pointless challenge. When the point of the game is to make use of the interactive objects, no one is going to enjoy scrubbing around the screen to identify the objects. Ho hum.
If your non-game app is tedious, it’s not because it’s insufficiently challenging. It’s because you’re making your users do pointless things -things that do not advance the user efficiently towards completing their task. Your web page makes users read through endless unorganized content to find the one piece of information they want. Your navigation structure forces users to go through the same pages they’ve already reviewed in order to get to where they want. Your menus force users to navigate slowly through many layers of hierarchical menus to get to each command.
The last thing you want to do is to add challenge to a tedious UI. You might think it would be more fun if navigating your menus required all the dexterity and finesse of navigating a race course in Mario Kart, but that would be a pointless challenge. Users are not using your app to “win” at using the menus. They’re using your app to find some content or copy and paste some text or set the properties of an object. Users will realized that you’re deliberately making the menus difficult for them and resent the pointlessness of it.
The way to remove tedium from your app is to strip away all the “excise,” as Alan Cooper calls it -all the things not directly relevant to the user’s goal. Organize your content and controls so users can quickly get to the ones they want. Reducing tedium means getting the UI out of the user’s way, leaving only the task.
We are naturally curious organisms wired to seek interesting things. It‘s not just a certain purposeful end state we seek. We seek stimuli that are optimally varied and novel, comprising new sensations or meanings. Stimulation that is too different to what we are used to is confusing or even threatening, but too much of the same stimulation is monotonous.
Normally we habituate to repeated stimulation, our perception of it fading until it becomes part of the background where it has no significant emotional effect. To be monotonous, the repetitious stimulation has to demand our attention, be something we cannot ignore. Remember what happened when my college roommate conquered Q*Bert. When he reached the highest level, the game still required his full attention -the game was still challenging, in the sense of demanding high mental effort to avoid losing. However, it had become monotonous: the board no longer changed, the hostile varmints no longer changed. At that stage, it was more interesting to see and hear something different, namely the effects of deliberately sending the creature off the edge. Thus, monotony is not the result of insufficient challenge. Rather, monotony can result from too much challenge when the challenge doesn’t change.
To remove monotony from your app, you either:
- Remove any repetition.
- Make any repetition require less attention.
To remove repetition, look to cut down on repeating navigation paths through your pages or menus. Clicking gets monotonous. Flatten your navigation, giving the hierarchy fewer layers, or provide shortcuts (e.g., accelerator keys). Remove confirmation and verification messages the user must navigate through each time they do an action. Instead, provide modeless feedback on the action and provide an obvious means to undo it.
Rely on the variability in the task to reduce monotony. Each day, the user needs to plan a different trip, or schedule a different meeting with different people, or write a memo on a different topic. That is equivalent to a game with new levels, new terrain, or new adversaries. Of course, sometimes parts of the task itself are repetitive. If that’s the case, then find a way to automate them. Automating repetition is what computers are good for. Allow users to select multiple objects and perform the same action on all of them at once. Allow the user to create templates or otherwise re-use work from previous sessions. Include a feature to check the users’ work in the background (e.g., spellcheck) so they don’t have to explicitly for each input one at a time. Provide a macro or scripting ability. Such advance features fight monotony in two ways: they reduce repetition in the task, and also learning the new feature itself is a change from the usual work the user does.
To make repetition require less attention, increase the UI’s consistency. Yeah, that’s counter-intuitive because consistency means more things are the same, which implies making them more monotonous. However, a consistent UI builds user habits. If you can’t remove the repetition by automating the app, then automate the user. Keep controls in the same location on all pages and windows so muscle memory builds and users don’t have to look to see where to click each time. Use the same keyboard accelerators in all pages and windows so users don’t have to stop and think about where they are before acting. You are looking to reduce user attention to the user interface.
Never vary the UI to try to make it “interesting” or “challenging.” That only makes repetitive actions more monotonous, not less. Changing menu names, graphics, or layout is like swapping a game’s Jump button to Duck at a certain stage; it’s not going to be fun even after users get used to it. If you have a monotonous website, then you need to vary the content more, not the UI. Books all have the same basic graphic design and interaction conventions once the readers open them, but as long as the content is new, they never get boring. Removing redundant content in a web site is like changing the game’s scene providing new things to explore.
A dull game is one where nothing happens. However, dullness doesn’t result so much from insufficient challenge as from insufficient stimulation. Humans naturally seek a optimal level of stimulation. We’re attracted to strong colors, shapes, sounds, and tactile sensations, these comprising basic elements of all arts. Too much intensity can be jarring, distracting, and annoying, but too little is dull. We experience dullness when we don’t have enough to focus our attention on.
The absolute intensity of optimal stimulation depends on our mood or task. The optimal level is lesser for tasks requiring “higher” mental processing, such as interpretation, reasoning, and planning, while the optimal level is greater for tasks requiring more passive, highly conditioned, or intuitive reactions. This is true in games as much as anywhere. Fast action and loud noises is just about right for a shoot-em-up game that requires little thought other than Blast That Sucker! Yeah, give them bigger, brighter, louder explosions. However, such intense stimulation would be an annoying distraction for contemplative “puzzle” games. Most tasks for non-games are of the puzzle variety: how to take a bus to the Mall, how to phrase an issue diplomatically in a memo, so generally you’re not going to want to provide strong stimulation. It’s not helpful to have the deletion of a word manifest itself as a desk-shaking explosion.
In any case, you can provide stimulation in your app without providing a challenge. User success can be guaranteed but you still provide the level of sights and sounds appropriate for the task to avoid boredom. Consider, however, that it’s easier for users to add stimulation to the task than to take it away. Rather than unilaterally increasing stimulation, give the user control. Don’t have background music that the user can’t stop and start, and (preferably) select. Consider that users might enjoy some stimulation other than what you choose for them. If dullness is an issue, maybe you want to design your app so it’s easy for users to provide their own stimulation. Make it easy to do side tasks of their choosing. For example, rather than increasing the levels and complexity of the sound feedback in your app, consider that users may want to listen to their own music while using your app, or consider they’ll want to hold a conversation -dull tasks are a lot less dull when done with a friend. Make it so sound feedback is not necessary to complete the task and let the user turn off the sound feedback.
From Boring to Exciting
Conventional wisdom has boredom and difficulty at opposite ends of the spectrum, with fun being an optimal level of challenge somewhere in between. However, this belies a commonality between boredom and difficulty beyond their negative experience. Both are about frustration. Frustration comes from a difficult user interface when the user expected to complete the task but couldn’t. Boredom also necessarily includes frustration. People are not necessarily bored when there’s “nothing happening.” Sometimes they like that. We’re bored when nothing is happening and we need something to happen -like get a task done. If users are bored with your app, then making it more complicated or challenging can just make it worse. On the other hand, users get excited and delighted when your app helps them get their task done faster, easier, and simpler than they expected.
Lesson 4: Gimmicks Aren’t Fun for Long
When confronted with a boring UI, designers seem to be tempted to add attractive but irrelevant features to make it more interesting. We add personalization, letting the user pick colors and images such as for a background. We add social features so users can comment about what they find on our websites. We highlight or animate things on mouseover. Rather than use a humble table, we show data in 3-D and let the user “fly” around it to explore it. We include cute characters in features like Search and Help. We show “smoke” when burning a CD. We add background music. These are all the sorts of things you’d find in a game.
This can work if your primary problem is dullness, where the task demands little attention and its stimulation is suboptimal. This is why students text during a college class lecture. It’s why health club members listen to mp3 players while working the ellipticals. It’s why cars for decades have had built-in radios. Lectures, exercising, and driving can all be mind-numbingly dull, so people seek additional stimulation.
Users can only do this, however, because the task demands so little attention. If the concepts in the lecture demand actual thought or interaction, rather than just copying down the PowerPoint slides, students will stop texting. If someone’s idea of exercise is two-on-two basketball, rather than running in place, they’re not going to be wearing an iPod. When surrounding drivers seem bent on executing kamikaze attacks on you personally, you turn the radio off.
This is the risk with adding irrelevant “fun” features to an app. They literally provide a diversion, distracting the user from the task. Yes, the user got a little amusement in, but it did nothing to shorten the boring part of the task. Users enjoy setting their desktop wallpaper for the whole 30 seconds that lasts, but it doesn’t make renaming 40 files any less boring. Once they actually get to using the operating system for their tasks, they don’t even notice their wallpaper anymore. All you’re doing is interspersing interesting things among the boring. Total boredom is the same.
To be fair, there’s no harm in providing things like personalization as long as it doesn’t interfere with the users’ tasks. However, adding irrelevant features can make the task last longer. Flying around a 3-D graph is cool until the users have to actually figure out complex relations among the data and are thus reduced to painstakingly constructing their own tables on paper so they see all the data at once. Where’s the fun now?
Playing versus Playing With
Irrelevant features are only fun for users who like to play with your app. It might surprise you to know that some users really liked Clippy, the cute anthropomorphic assistance feature in older versions of Microsoft Office. However, dig down into what they liked about Clippy, and you find they liked playing with him, not using him. They liked to select Animate from the context menu to see what he’ll do. However, when it comes time to actually provide assistance on a task, Clippy could be an annoying distraction. Worse, for some users it just didn’t work for its intended task. Users came to hate Clippy if its search results failed to provide Help topics to solve their problems. Similarly, zooming around a 3-D graph is fun for just seeing what the graph will do, but not so fun for actually trying to understand the data. My desktop wallpaper for my monitor right now is set to display a single color. Sure, it might be fun to set it to be any number of my photographs on my hard drive, but, frankly, I’ve too much other “real” work to do (like trying to get this post out before all the leaves change) to spend time on that.
There’s a huge difference between using an app and playing with an app. What are you designing for? How many users want to take the time to play with your app as opposed to actually accomplishing something? Perhaps surprisingly, the same is true for games. There’s a huge difference between playing the game and playing with the game. When users play with your game, they’re not trying to accomplish its objective. They’re doing things like deliberately sending Q*Bert repeatedly off the edge. If your users are playing with your game rather than playing your game, then you know you have a boring game.
Some people apparently enjoy trying to figure out how to use obscure features on their smart phones during dull commutes when there’s nothing else to do, like, maybe call a coworker or friend. However, that just shows that the only time an unusable UI is fun is when a user is trying to figure it out just for the sake of trying to figuring it out -when it becomes a game, in other words. Oh, look, this is how to edit a photo in the phone, not that anyone would ever actually want to do that, but now the user can boast about it to coworkers over lunch. I could see that as fun, sort of the same way training a dog to do tricks is fun, although in this case, I’m not sure if the phone is the dog or the master. In any case, the ideal design for a non-game app helps the user accomplish their tasks as well as have fun doing it.
An Interesting Task, not an Interesting UI
Likewise, if you observe users playing with your app, it probably means the task it’s design for is boring, and they’re seeking a diversion. The best solution to boredom is not to add diversions, but to make the task more interesting. To paraphrase Edward Tufte, if your users are bored with your table of data, maybe you need more interesting data, not a zippy 3-D interactive user interface. If your website is boring, work on the content, not the AJAX or graphic design. Make your content relevant to the users. Make it about people or make it personal. Structure it as a narrative with comparisons and contrasts to create some dramatic tension. Make it clear why the user should care. Making your site look exciting isn’t going to make it exciting if the content is boring.
I’m not saying every web page should have black text on a white background with #00F-colored links. I am saying you need to make the content interesting before that matters. Then, make your graphic design consistent with your content and the message it gives. Peppering boring content with unrelated hyper font, trendy controls, swoops of colors, and cute characters is just marketing gimmicky that tries to persuade the user the site or app is fun without being fun. Gimmicks provide no fun once users actually get in your site to complete their task, and find they can’t. And, ultimately, such gimmickry will look as out of place as a Mario brother strolling into an Everquest scene.
As designers and developers, it’s easy for us to get excited about the latest control or visual fashion and start to look for excuses to use it. We admire clever solutions to difficult design problems. We have fun studying web sites and apps and seeing what was done. The average user doesn’t care about any of that. To them, the design is the background and the task is the figure. Users are not design-enthusiasts. All they want is a design that looks nice and doesn’t get in the way. If you really want your users to have fun, don’t design to impress your colleagues.
Redefining the Task
In some cases, tasks may be just inherently boring. Filling out yet another daily TSP report is just plain tedious and dull for the users in the movie Office Space. If you’re lucky, you’re doing more than just interaction design, but activity design, going beyond the user-interface to re-working business processes and consumer pastimes. From this higher level perspective, if you want your users to have more fun, then your goal isn’t making that task fun, but creating a fun task. For example, maybe you can eliminate TSP report process by replacing it with tasks that serves the business just as well while being more stimulating for the users.
Among consumers, if you want to make a task inherently more fun, then you need to change the nature of the task itself, or create a task that didn’t exist before. There was never anything quite like blogging until it was invented, but now it provides fun for writers and commenters alike. To access that fun, it only has to be usable. Users have fun listening to music or podcasts, not pressing buttons, so they don’t need a fun mp3 player, just a usable one. If you want to make the podcast/music-listening more fun, change the task. For example, make an mp3 player that allows users to easily patch in friends so they can all be listening to the same content. That would change how users listen to music. If you really want to make exercising fun, don’t build a TV into your exercise machine. Build a virtual reality interface into it. Let users use the stationary bicycle to ride a different leg of the Tour de France each day. Heck, let them race the Tour de Titan.
Lesson 5: The Beauty of the World Matters More than the Beauty of the UI
Why do people enjoy climbing Mount Everest, but not putting their hand on a hot stove? The stove probably hurts less. There are several reasons: climbing the world’s tallest mountain, unlike burning one’s own hand, is socially consider to be an Accomplishment -something worth putting on a resume. There’s the camaraderie of fellow climbers, although for all I know there’re secret underground Put Your Hand on a Stove clubs (”First rule of PYHOAS Club…”). The biggest factor for most climbers is probably the pursuit of beauty: to see some incredible views, to experience a direct connection with nature, terrible and wonderful at the same time, to understand oneself and world. It’s more than superficial beauty of the senses, but the beauty of being part of a Larger Order. People want to see great things and do great things.
There are at least three kinds of experiences of beauty:
- Sensory beauty that comes from what people see, hear, or physically feel. Some sensations are more attractive than others. For example, visually we like certain color combinations, textures, and compositions.
- Cognitive beauty that comes from what people understand. Certain forms of knowledge are attractive: an elegant theory, a ingenious solution to a problem, a good story, a clever joke, a significant idea. It seems that deep understanding of anything yields the experience of beauty, a state that psychologist Abraham Maslow called “B-knowledge.”
- Action beauty that come from what people do. When people become absorbed in their actions, at once fully attending to them yet acting effortlessly and intuitively, then people can enter a “flow” state, as psychologist Mihaly Csikszentmihalyi called it, where they feel a sense of beauty in their own interactions with the environment.
Most things people do for fun involve the pursuit of at least one of these forms of beauty, of immersing oneself in something aesthetically attractive. Certainly, this applies to most media entertainment, but also for more interactive things. It’s in the sight of well-polished fenders of the antique cars they restore. It’s in the sound of the guitars they’re playing. It’s in the feel of the edges of their skiis digging into the snow as they swoop down the slopes. The same is true for games. Part of the fun is having beautiful, or at least cool-looking things, to look at. A catchy soundtrack helps too. Rarely does a truly new computer game come out -most of the genres of today were around back in the time of Q*Bert -yet each year we see a new crop of games on the market. What users get each year is new and improved graphics.
However, for maximum fun, the graphics and music are not enough. To have cognitive beauty, your game needs a backstory, the Larger Order that gives the game its significance. Then the game-play itself must constitute a compelling story. Part of a good story is the dramatic tension that a challenge creates. But equally important is that the story have a certain “rightness” to it. There can be surprises, but the surprise must fit with the Larger Order presented initially. The game Portal would’ve been less fun if after completing all tests, hey, it turns out we get cake after all, and everything is okay. It would’ve been even less fun if it ended in the middle of the final countdown with the protagonist waking up to find it was all a dream. Your game players will feel cheated by deus ex machina endings unless the users’ emerging understanding of the game’s Larger Order is consistent with machinas naturally exing deuses. The puzzle must have a beautiful solution.
Finally, users have the most fun with games when users enter flow, when the game provides the well-designed controls and immediate and intuitive feedback necessary for beautiful actions.
Moving to non-game apps, we see much of the same story. An attractive UI can make using an app more fun. And, fortunately, a usable app can be a beautiful app. However, once again, we need to recognize the distinction between the tool and the task. The controls, fonts, and dialogs are the tool, but the beauty users seek is mostly in the task. What does your website do to connect your users with the beauty of the topic? This isn’t restricted to web sites about profound matters. You can do it with a website for a transit service, for an example, by showing the meaning of the transit system. Show subtly with your web site the physical symmetry the system has, or it’s congruence with the life of the city, or how it evolved to its present state. Provide your users with insight into its nature.
Or take a word processor: how can it help the user make beautiful documents? You can make it easy to create attractive graphics or tables to give the memo a satisfying look. Promote sensory beauty by encouraging the use of elegant layouts and fonts, but also consider cognitive beauty. What can you do to help writers understand their own thoughts on the topic in order to write more beautifully? How can you engage your user’s creativity? Removing any distractions from the UI is essential for this, not interrupting the user with message boxes and not troubling the user with technical aspects of using the word processor, like saving frequently or providing a filename. Beyond that, consider what you can do to make the writing itself less distracting. You can provide a well integrated thesaurus so the user is more likely to get just the right word. Automatic spelling correction, for example, removes one thing that may distract users from their thoughts, but only if it’s reliable enough that the user can simply ignore it. Then there’s action beauty. To get users in the flow you need an intuitive powerful user interface with fast easy-to-interpret feedback, the sort of the thing that direct manipulation provides. Once again basic usability makes an app fun.
A beautiful tool still counts for something. A driver uses a sports car to pursue the perfect drive down the perfect road, but she or he still enjoys the looks of the car. However, the driver doesn’t really see the car once the drive is on. Ideally the car disappears and the driver feels only a direct connection with the road. Likewise for the visual design of your user interface. Attractive menus and other controls help, but for the user to experience beauty, they ultimately fade as the user becomes immersed in the task. Hot graphics are not going to make a miserable task fun. Worse, they can make the users feel cheated, like you gave them a fast looking sports car, then only let them drive it in the swamp.
Lesson 6: Most Users Don’t Like Most Games
A lot of fun is choice. Not everyone likes a particular game, even popular ones. I never got into Q*Bert. Even when people like a game, they don’t like it all the time. They have to “feel like” playing the game. By making a fun app, you can get some users to use your product more and enjoy it more, and maybe some subset of users will even become passionate about it. But you need to keep your goals in perspective. The simple fact is that you have an app intended to support a task and no matter what you do, most users are not going to be passionate about the task. An individual can only be passionate about a few things in their life. What are the odds it’s going to be mass transit? Or writing memos? No matter how much fun you can make it, not all users are going want to get that invested in your task. Only a few things in life are worth the effort of having fun.
Sure, it could be fun to turn a web site about a transit system into something like exploring the Mines of Moria, but most users just don’t care about mass transit that much no matter what you do. You can turn book-buying into an epic search for the best deal, but how many people care about being the Great White Book Hunter? Some people are passionate about fashion; others are just trying to stay warm and reasonably modest. Most are in between. Who are you making your clothing e-commerce site for? True, the passionate users may have more per-person long-term return, but in sheer number of users, the market for the middle is vastly larger. If your app attempts to force fun on users, then it won’t be fun at all for most users. It needs to be something your users can pursue at their own option.
Problem: Providing user fun and enjoyable experiences in your non-game app.
- Recognize that you need to make the task fun, not the tool.
- Recognize that success, not challenge, makes non-game apps fun.
- Avoid boredom by
- Removing pointless interactions.
- Removing repetitious interactions.
- Increasing consistency.
- Allow user to add stimulation of their choosing.
- Avoid irrelevant amusements.
- Recreate the activity if the activity is inherently unenjoyable.
- Lead the user to beautiful sensations, knowledge, and actions.
- Provide beautiful content on your web site.
- Help the user create beautiful things in your app.
- Achieve fun by being functional.