Did the excitement factor for your last custom application rank right up there with a visit to the dentist? Make your next application a success by catering to user needs, desires, and delights.
Shhh… This article contains secrets derived from the innermost thoughts of users. I actually stooped to asking users what bugged them most about applications, as part of preparing a book proposal regarding Application Performance Monitoring. If you use these secrets when you create your next application, be prepared for the not-so-subtle award of user acceptance and excitement.
It’s no secret: Developers, devops, administrators, managers, and users have completely different perspectives on applications. A developer may seek elegant coding solutions, interesting user interfaces, and a place to provide creative output. But devops are trying to bridge the gap between administrators and developers, and administrators simply want the application to run reliably. Management’s primary concern is the bottom line or at least ROI, which – in the worst cases – means everyone must rush to develop a substandard solution that sort of works in the required time and for the specified dollar amount.
The user, who usually gets left out in the cold, simply wants the application to disappear. That’s right: A user really doesn’t care about that elegant code or the need for a reliable application. All the user wants is to get some work done and then go home for the night without a massive headache from using the software you so carefully crafted. The moment that the user has to think about your application, even a little, you’ve lost the battle for the user’s attention and the user definitely won’t express any form of excitement.
Yet, you want your users to care about the software you build. First, there’s your ego; we all like to be admired, especially for something on which we spent a lot of time and creative energy. And, whether you’re an on-staff developer or an outside consultant, it’s good for your career to earn praise – or at least acknowledgement – from the people who can give you raises or more freelance assignments. If users appreciate the custom software you build for them, and tell their managers about it, you get better bragging rights.
Make It Simple
“The task of the software development team is to engineer the illusion of simplicity.”—Grady Booch
A recent article talks about Steve Jobs’ obsession with simplicity. The reason that the iPhone, iPod, and iPhone have all taken off is that you don’t really have to think about them. You just use them.
Simplicity is the reason that apps are so popular with users today. You download an app and instantly use it to perform a single task. The app doesn’t require any instruction book, it works quickly, and you barely notice that you’re even using software.
In fact, most users zone out on the whole aspect of apps as software. Users don’t see the software—they see the app. They see an application as the answer to a need. It’s the reason that Microsoft is investing so much in Metro (or whatever we’re calling the interface this week). Apps generate excitement because they do something without any need for the user to become computer savvy.
Realistically, not every application can be an app. You can’t address every need with something so mindlessly simple that the user doesn’t need to think about it at all. Some custom applications have a lot of working parts.
But you can make most applications simpler. For example, several sources make it plain that Steve Jobs would agonize over interface issues, going so far as to say that no task should require more than three mouse clicks. Microsoft obviously saw the same problem when it moved away from the menu and toolbar interface toward the Ribbon interface.
You see it in everyday life, too. Anyone can drive a car and no one complains about the interface, but hardly anyone can program electronics equipment and you hear everyone complain about it (well, except for us gadget freaks). The idea is to hide complexity and make common features instantly accessible.
The problem for most developers is that we like complexity. After spending a lot of time trying to clean up my own interfaces, I know that I need help in trying to define simple. That’s one reason why you need to have users involved in interface decisions from the outset. I’m not talking about that power user who can simultaneously use two different applications on two different machines while juggling four iPhones and singing the Star Spangled Banner. No, I’m talking about the user who’s’ constantly complaining about everything being too hard to use—that’s the user you have to get input from. That’s the squeaky wheel who’s willing to say the things that every other user is thinking. When your interface is too complex, the other users won’t say anything, but they also won’t use the application.
Make It Fun
Applications should be fun to use. Anyone can create work, but most of us don’t want to work—we want to have fun. Fun is currently part of many training programs. For example, McDonald’s in Japan is using the Nintendo DS to train new employees in how to interact with customers. Even the US military recognizes the value of fun in training. The Army uses video games (to the tune of $50 million) to train soldiers for combat operations now.
The fact that games are recognized as a means for making training stick should tell you something about applications and the people that use them as a whole. People like to have fun. If you can find a way to make your application fun to use, people will look forward to using it and will be more productive as a result. No, we’re not talking World of Warcraft here, but anything you can do to stimulate the pleasure centers in the user’s brain is good.
Don’t get the idea that you’re really creating a video game. Work is serious and so should be the fun you create. If your application includes what-if scenarios, using a gaming interface to create a fun environment, but make the output serious. This has become a popular way to engage users, in the last few years, whether with location-based computing like FourSquare or solving the structure of a retrovirus enzyme. Gamification is “the concept of applying game-design thinking to non-game applications to make them more fun and engaging.”
Of course, the fun you add to the interface should never make the interface more complex. The top priority is the rule of making it simple. In addition, make the fun simple.
When creating fun software, the biggest thing to avoid is cute. Microsoft’s Clippy was a fun concept that went horribly wrong. I’ve seen videos on You Tube entitled, “Clippy Must Die!!!” (and no, I didn’t add the extra exclamation marks). If you find that you have no idea of what a user is going to consider fun, take time to ask. For that matter, ask a whole bunch of users.
As part of making a user interface fun, you have to consider the roles of aesthetics (anything that appeals to the senses) and cognition (the process of knowing). If you see a screen element that looks like a button, you expect it to act like a button and not like a checkbox. Your mind says “danger” when you see something in red, but green is associated with something good. The use of shading, color, and animation in your application is an important component.
The most important thing to remember is that emotion is part of the basic human experience. If your application fails to generate the right emotional response, it will always generate a negative emotional response. Humans don’t operate in an emotional vacuum.
If you want people excited about your application, don’t withhold information about it. Anytime you keep something secret, it generates rumors; the more secret the item is, the more rumors that it creates.
Select specific users, hopefully ones with really big mouths, to try out your application and tell everyone about how great it is. You want people to know how hard you’re working to address any issues they find. You want these users to feel appreciated and involved in creating the application. The more buzz you create, the better. Everyone should be talking about the application long before it arrives on the scene.
Buzz is good for another reason. If people are talking about your application early enough in the design process, you can learn about potential errors and correct them before they become a problem – or ruin their opinion of you and your software.
After advertising your application and making the user salivate over it, you want the user to have an exceptional experience using it. Do everything you can to generate a cool factor for your application. Yes, this is the coolest application on the planet and everyone wants to use it. You want to make the application appear so neat that no one wants to be left behind when the application eventually does make it to the production environment.
Of course, you also don’t want to delude yourself. Anyone who thinks cool comes easy had better think again. Cool takes a lot of work, especially for “boring” tasks like training flash cards or accounts payable or backup software. You need to spend time talking things up, but you also need to spend time actively listening to user complaints about mockups and early iterations. Users will tell everyone but you about the problems they encounter. Make sure you have your ears out there listening to complaints and making you aware of them so that you can fix application problems before anyone actually uses the application. Remember, first impressions count more when you’ve generated a lot of buzz for you application (but the payoff is so big that you really do want to take the risk).
Make the Name Count
What’s in a name? The future of your application! Look at the names of some of the most influential software in history and you quickly find that the name has something to do with it. The name should be simple so people can remember it. Product names such as Office and Windows are easily remembered. People can’t tell anyone about a product with a long goofy name that may be more descriptive, but ultimately lost on the user who doesn’t really care about the name anyway.
The name should be descriptive of the task that the application performs. If nothing else, run a contest, open to everyone, to name your application – that’s gamification, again. Someone in your user community will come up with a short descriptive name that people will remember with ease.
Once you have a name, use it to generate buzz. If your company has a newsletter or some other means of communicating with employees, make sure your application is in it. Tell people about the progress you’re making and let them know about the need for users to test the application fully. Most importantly, keep emphasizing cool features that everyone asked for, so users know that their input really does count.
Excitement is an emotional response to stimulus you provide. If you aren’t excited about your software, then no one else is going to be excited either. Making things simple, transparent, and fun induces users to interact with the application you create and find out that it really is an interesting application to use.
It’s important to view excitement as the invitation to use your application. The application you create must still provide a superior user experience or everyone will get disgusted and throw it away. The way you ensure that everyone loves your application is to get plenty of user input and to rely on creative solutions to interface problems. Make sure you add the fun into the interface!