Funware is only fun if people understand what the hell is going on. How hard is it to confuse people by putting a game where they weren’t expecting a game? Well, it depends on the user experience… and sometimes users are more easily confused than you ever imagined.
This post will explain the potential usability problems if you add funware to your existing user experience, and what types of users are most likely to be impacted (hint: it’s not the dumb-as-dirt minority you are probably scoffing at already). In the conclusion, I’ll give 4 actionable tips to improve the usability of your funware (and drastically lower the chance that your funware will drive users to drive their tech support staff crazy).
“I Have the Pac-Man Game and I Want to Disable That?”
Have you heard the audio recording of a tech support call resulting from Google’s super-cute interactive Pac-Man logo? This poor woman uses Google for productivity and instead she found a noisy game on the Google search page, so she called tech support to try to get the game removed.
Awkwardness ensues, but the tech support hero helps her work through the problem (which is mainly that the game sounds are still audible while she is trying to do other stuff in her browser, the way she probably does every day). If you’re a good software designer you are going “oh that’s a problem, hm… how could they have avoided this issue” but if you’re a less user-focused software designer you’re thinking “what a dumbass, there were several ways for her to work around this without calling tech support.”
If you’re in the latter camp, you need to go work in tech support for a while. Seriously, it is boring and repetitive and you rarely get to solve any interesting problems but you can’t design good software unless you understand what it’s like to be a “pure user” with no idea how to troubleshoot or work around a software experience that doesn’t match your mental model.
The majority of tech support calls are from people who use their computers for very specific tasks, and then one day, something is different. They don’t know why or what to do about it, but they know that whatever they expected to happen with their computer did NOT happen. That the user cannot figure out a solution on their own is no more a personal failing than when your car breaks down or a flight is delayed and you need to seek a mechanic or an airline employee to find out what’s going on.
Ok, but you’re not going to actually quit your job and go work in tech support. Here’s the next best thing, just listen to the above-mentioned Google Pac-Man logo tech support call, if you haven’t already:
What if that was your website or application? Would you want your customers to feel that lost, stupid, incompetent, or frustrated? Probably not, but neither did Google.
However, that lady was not alone in her confusion: many people had problems with the game’s audio, including Sam Diaz, senior editor at ZDNet (and I really doubt he’s a computer illiterate kinda guy). So clearly, there were some real technical issues with the game even when a user grasped the “Google changes the logo to a game for fun” concept. The result of the auto-playing, unmutable, unclosable Pac-Man logo was frustration and confusion for many Google searchers that day (followed by a rash of commentary on how counterproductive the surprise game may have been in terms of lost worker time and money).
Google added funware to delight Google search users, not to confuse them. So what went wrong?
Noob User or Noob UX Design?
Is this lady just a moron? Or is it moronic to assume you can stick Pac-Man on your productivity tool randomly, for one day, without confusing the hell out of some people? I’m hoping to convince you that it’s the latter. That woman was probably no dumber or less intuitive than the average user of most websites and apps.
We’d all like to think that the only reason some people get confused by software is that those people are idiots, but there is a certain responsibility we all share to make software usable.
Software should pretty much work the way people expect it to, or compensate for user experience anomolies by effectively reorienting the user. If you change something significant, you have to take the user gently by the sleeve and say “it’s okay, you’re still in the right place, but we made a change and this is how it works now” because too many people lack the mental model to effectively self-troubleshoot a technical or usability problem with a website or app.
I’m also going to try to convince you that it’s easier than you might think to confuse even your “smartest” customers with random whimsical weirdness they weren’t expecting because users have mental models of how stuff works. Software and web sites work a certain way, and offer certain expected features, based on the user’s past experiences. When you dump your new funware features into an experience that already has a mental map that is incongruent with funware, you are responsible for designing an informative, gentle segue from the old mental model of how your software works to the new one that includes funware, marketing games, or reputation systems.
Also, you should give people a graceful, easy, unobtrusive way to learn more about your funware and to opt-out or turn off the funware portions of the user experience if the user is just not digging it (especially if there is ANY audible feedback as there are few things more unforgivable than audio on a web site or app that can’t easily be silenced short of muting all system sounds).
Battle Tactics from the Tech Support Frontlines
Extremely not fun fact: I used to work internal tech support; first at a large, local government agency and then at a very large downtown-Minneapolis hospital. Despite the monotony of the work, I was actually pretty good at helping people. It’s primarily a customer service job in that the biggest challenge is listening, communicating, and figuring out what the user’s actual problem is (the user has no idea most of the time, and they are usually frustrated beyond helpful communication by the time they call tech support).
I am glad for the experience helping all kinds of people use software. It was eye-opening. It’s too easy to forget what software looks and feels like to people who have no idea how to build it. Games and funware are the same: the experience from the viewpoint of a “pure user” with no idea how the systems work is totally different from the experience of a game developer.
Here’s the biggest lesson I learned working in the tech support trenches: your users may be tech support n00bs, but they are not dumb or lazy. Just like you are not dumb or lazy because you need to visit a doctor to find out what’s wrong with your body. People generally don’t have problems with computers because they are idiots, so much as they have problems because software was not designed to be friendly enough to all users.
Many of my callers were extremely intelligent, experienced computer users with graduate degrees or higher: nurses, doctors, civil engineers, and high-level executives. But I also supported the clerical staff, the housekeeping and cafeteria staff, everyone who works at the city bus and lightrail (from drivers to mechanics), everyone who worked at the wastewater treatment plants (where nearly every computer had whitelist internet access only because so many of the workers had been caught enjoying porn on the job), and many other folks from all levels of education and work experience.
You might be surprised that some of the most jaw-droppingly dumb calls I handled came from the folks with the higher education (and much higher salaries); people with more gadgets, apps, and peripherals than they had time to learn how to use it all. Basically, I’ve found that people of all experience levels frequently run into tech support issues when their mental model of how something is supposed to work just doesn’t match reality. Intelligence, experience, and education just don’t factor in when a busy person is trying to do a specific task and something just is not working as expected. They just need it fixed, don’t care to figure out how, and they often need to call a tech support worker.
As you design your funware, realize that it’s software and it typically will need to intrude on the user experience and user interface (or else the user won’t even know the game is afoot). This means your funware is in a position to cause tech support problems if you do not make a basic effort to integrate the funware into the mental model your user has of your product, service, web site, or tool.
Please, Think of the Tech Support Workers
A little foresight and some user-friendly design will prevent your funware from causing that tech support call. Your users (and their go-to tech support team) will thank you.
- Add a Close button. Whether you use the Windows style X button, a Mac style button, or the word “Close” with a hyperlink, just include some way that a user can dismiss your funware. That leaderboard you put on their profile page (you know, the one that does the fancy AJAX shit to update without page reloads) might be genius to your team, but I would bet at least some of your users want that thing gone. Now. Most professionally designed websites feature sophisticated CSS these days so it should be no problem to let users hide and show various page elements at will. Being able to close all or part of your funware UI will go a long way toward pacifying a user who doesn’t understand or enjoy the funware today (and I really do think that a person’s mood on a particular day can be a huge factor in how they receive a tickle from your new funware app as annoying versus delightful).
- Add a mute button. This should be self-explanatory. If your funware has sound effects of music, you need to provide a mute button that turns all sounds off completely. That is the bare minimum you can do, especially if your funware auto-plays. Optional enhancements include a volume control and setting a cookie or server-side setting so that your user’s sound preference is retained for future sessions. Also, there are special considerations if your funware app fires any type of audio notifications to the user (status pop-ups or alerts). If you have event-driven sound effects that might interrupt the user while they are multitasking in another app, consider adding a very simple way for people to silence those alert sound effects (or customize them to shut up under certain conditions if your users ASK for this kind of fine-grained control). This is probably a good place to note that best practice for new games is NOT to shove all your player options into some convoluted multi-level system menu because it is irritating to have to click through 4 sub-menus like Options>Audio>Alerts>Exceptions to get to the right setting. Most people do not want or need super fine-grained control over audio in your funware. Just let them turn sound on or off quickly and easily, preferably with one click (an elegant little speaker icon in the corner of the alerts or app is a good solution).
- Add an info button. A small question mark icon will do, but I like the “what is this?” text link because it doesn’t require the user to mouse-over the icon for a tooltip to confirm the question mark is an information button. This is where you gently explain to your user what your funware is doing on their web page (especially helpful if you are plopping some game stuff into an experience that previously had zero game stuff). If you are not a good copy writer, use Twitter or Google to find someone who is great and pay them a small sum for a VERY short blurb explaining your funware to your particular user base. This one little courtesy feature could literally mean the difference between your user getting back to work/life as usual… or your user spending ten minutes on hold listening to Kenny G, followed by ten minutes trying to explain to a weary tech support person that there’s a Pac-Man in their productivity tool.
When you design your funware, do you ever ask yourself “what if my user is not expecting this game” (or if you still prefer “what if my user is a complete idiot”)? Add a Comment