It’s no surprise that users have expectations that, if not met, make those users angry and frustrated. User think every programmer can make everything that user wants. Here are 10 common user expectations and what you can do to meet them so that you'll have a happy group of users.
First : Accurate data
Nothing on the planet can set a user off like seeing inaccurate data on the screen. “Inaccurate” covers a huge amount of ground, in the users’ eyes. For example, if a package has been delivered but the courier’s Web site shows that it is still 200 miles away, that isn’t “out of date” to the user, it is “inaccurate.” Another winner is when item information on an invoice or account history has no resemblance to the product that was ordered; this is sure to generate a few frantic calls to the customer service department. The potential for user pain is limitless within this category. Unfortunately, many of the root causes of inaccurate data are out of the developer’s hands: user error, insufficient information, failure to follow processes, and so on. But enough of it is within our power to at least make a dent in the problem. Make sure that your application validates all data, contains rules for performing “sanity checks” whenever possible, requires the right data, and uses atomic transactions instead of batch processing whenever possible.
Second : Responsive UIs
If there's one surefire way to make users angry, it’s to put the dreaded hourglass on their screen. For extra credit, block the main UI thread entirely so it doesn't respond to user input and looks like the application is hung. If they don’t kill the application completely, they sure will be shocked when it suddenly starts to respond like a ghoul rising from the grave (brain eating optional). If you really want to annoy them, have it suddenly process all of their frantic clicks and other inputs. Nothing can cause users to fly off the handle like finding out that their work was destroyed by keystrokes sent while the application looked hung. Provide them with the experience they expect and deserve: Perform long-running processes in a separate thread to allow the UI to update, give them a progress indicator that makes it clear that the application is not hung, and offer them a useful and responsive cancel button if possible.
Third : Easy logins
One of the most frustrating things for users is when they don't use a service often enough to really remember a username -- and the username they have on that service is hard to remember. For example, I use “seagate” for many Web sites, but sometimes that is not available, so I might end up with “seagate” or something else, and I use site only a few times a year. The frustration comes in when I keep trying passwords with the username “seagate” and I forget that this is a site where I have the unusual name. That’s when I start asking myself if I really need the site at all. You should either have a prominent “forgot your username?” system or just use the e-mail address, account number, or some other piece of information that is unique to each user but is not an arbitrary username.
Fourth : Consistent input
Some Web developers seem to think that it makes sense for the phone number field to have a different input box for each part of the phone number and to make the cursor automatically move to the next part of the phone number field when the current one is filled. This does make sense in a way, but it doesn't make too much sense to users unless all of the fields they encounter behave the same way. Do your users a favor and save yourself some work in the process: leave these fields alone or just have the phone number be one large text input.
Fifth : Compatibility
A long time ago, when people went to stores to purchase software in boxes, it was common to have to spend 15 minutes studying the box to determine whether it would run on your system. Now, as long as the application runs on your OS, it's hard to find a machine made in the last few years that lacks the physical specs to run the non-game applications out there. Nonetheless, application incompatibility still exists. Ironically, it is most common on the supposedly platform-independent Internet. With the exception of some “must-have” enterprise class application, there is no way that a user or organization is going to jump through hoops to make your application run or your Web site work. So instead of driving away potential users, find and fix the incompatibilities. Obviously, that doesn’t mean that a Windows application needs to be made to run on Linux; but it does mean that a Windows application should work on XP, Vista, the upcoming Windows 7, and possibly even 2000. Likewise, your Web applications should work on Internet Explorer, Firefox, Opera, Safari, and Chrome across OSes without a loss of functionality or significant differences in appearance.
Sixth : Reasonable resource consumption
It really does not make sense that a keyboard needs 200 MB worth of software to be installed to work or that a simple text editor should require 1 GB of RAM to run. Yet it seems that more and more applications are huge resource hogs. It seems like every minor application out there is nearly as large as Microsoft Office was five years ago... and Microsoft Office itself is now the size that an operating system was a few years ago! Users expect better, and so should you. Cut the bloat. Ask yourself if your application really needs 100 MB of stock images of people using their laptops on the beach or 30 MB of custom sound files. Chances are, it doesn’t.
Seventh : Documentation
We all know how much developers dislike writing documentation. So we tell ourselves that the application is so easy to use, “only an idiot would need a manual.” There are two problems with this thinking. The first is that the world has plenty of idiots in it. The second is that we are usually wrong about how easy the application is to use. If your organization has a technical writer to create the documentation, involve that person from the get-go; the top complaint I hear from technical writers is that they are handed a nearly finished product and told to document it, with little insight into how it actually should be used. If you do not have a technical writer available, you will really need to work hard to make sure that the documentation does not merely state the obvious and is written in a way that will be helpful to end users who are unfamiliar with your application.
Eighth : No surprises
Some applications are filled with surprises. Of course, the definition of a “surprise” is that users don't expect it. But at a higher level, users expect that nothing will come at them from left field, either. This covers a lot of territory. Here are some examples of things your application should not do:
Ninth : Easy data backup/restore
Some applications are notorious for being difficult to back up and restore. Some applications hide their data in areas that might not get backed up (especially when the user prepares to move to a new PC or do an OS wipe/reinstall). Microsoft Outlook Express immediately comes to mind, since it buries your mail in the Windows folder instead of user data. (I once lost five years' worth of saved e-mails thanks to this.) Other applications like to lock their data in a way that backup applications can't back them up properly. Make sure that your application puts its data in the appropriate places to allow it to be easily backed up, restored, transferred to a new PC, and so on, and test common backup applications for compatibility with your application, even while it is running, if appropriate.
Tenth : Does what it says it will
I know, this one is just plain silly, right? It makes perfect sense that if an application claims it will do something, that it actually does it. (Doing it well is optional.) At the same time, far too many apps not only fail to meet users' assumptions, but they do not deliver on their explicitly stated promises either. While this may bring up the traditional issues of salespeople and marketing departments promising beyond reality, the simple fact is this: If a user has paid for a particular feature set, you need to deliver that feature set, one way or another. Don’t let your users down by delivering an application that says it does ABC, but only does A and C!
First : Accurate data
Nothing on the planet can set a user off like seeing inaccurate data on the screen. “Inaccurate” covers a huge amount of ground, in the users’ eyes. For example, if a package has been delivered but the courier’s Web site shows that it is still 200 miles away, that isn’t “out of date” to the user, it is “inaccurate.” Another winner is when item information on an invoice or account history has no resemblance to the product that was ordered; this is sure to generate a few frantic calls to the customer service department. The potential for user pain is limitless within this category. Unfortunately, many of the root causes of inaccurate data are out of the developer’s hands: user error, insufficient information, failure to follow processes, and so on. But enough of it is within our power to at least make a dent in the problem. Make sure that your application validates all data, contains rules for performing “sanity checks” whenever possible, requires the right data, and uses atomic transactions instead of batch processing whenever possible.
Second : Responsive UIs
If there's one surefire way to make users angry, it’s to put the dreaded hourglass on their screen. For extra credit, block the main UI thread entirely so it doesn't respond to user input and looks like the application is hung. If they don’t kill the application completely, they sure will be shocked when it suddenly starts to respond like a ghoul rising from the grave (brain eating optional). If you really want to annoy them, have it suddenly process all of their frantic clicks and other inputs. Nothing can cause users to fly off the handle like finding out that their work was destroyed by keystrokes sent while the application looked hung. Provide them with the experience they expect and deserve: Perform long-running processes in a separate thread to allow the UI to update, give them a progress indicator that makes it clear that the application is not hung, and offer them a useful and responsive cancel button if possible.
Third : Easy logins
One of the most frustrating things for users is when they don't use a service often enough to really remember a username -- and the username they have on that service is hard to remember. For example, I use “seagate” for many Web sites, but sometimes that is not available, so I might end up with “seagate” or something else, and I use site only a few times a year. The frustration comes in when I keep trying passwords with the username “seagate” and I forget that this is a site where I have the unusual name. That’s when I start asking myself if I really need the site at all. You should either have a prominent “forgot your username?” system or just use the e-mail address, account number, or some other piece of information that is unique to each user but is not an arbitrary username.
Fourth : Consistent input
Some Web developers seem to think that it makes sense for the phone number field to have a different input box for each part of the phone number and to make the cursor automatically move to the next part of the phone number field when the current one is filled. This does make sense in a way, but it doesn't make too much sense to users unless all of the fields they encounter behave the same way. Do your users a favor and save yourself some work in the process: leave these fields alone or just have the phone number be one large text input.
Fifth : Compatibility
A long time ago, when people went to stores to purchase software in boxes, it was common to have to spend 15 minutes studying the box to determine whether it would run on your system. Now, as long as the application runs on your OS, it's hard to find a machine made in the last few years that lacks the physical specs to run the non-game applications out there. Nonetheless, application incompatibility still exists. Ironically, it is most common on the supposedly platform-independent Internet. With the exception of some “must-have” enterprise class application, there is no way that a user or organization is going to jump through hoops to make your application run or your Web site work. So instead of driving away potential users, find and fix the incompatibilities. Obviously, that doesn’t mean that a Windows application needs to be made to run on Linux; but it does mean that a Windows application should work on XP, Vista, the upcoming Windows 7, and possibly even 2000. Likewise, your Web applications should work on Internet Explorer, Firefox, Opera, Safari, and Chrome across OSes without a loss of functionality or significant differences in appearance.
Sixth : Reasonable resource consumption
It really does not make sense that a keyboard needs 200 MB worth of software to be installed to work or that a simple text editor should require 1 GB of RAM to run. Yet it seems that more and more applications are huge resource hogs. It seems like every minor application out there is nearly as large as Microsoft Office was five years ago... and Microsoft Office itself is now the size that an operating system was a few years ago! Users expect better, and so should you. Cut the bloat. Ask yourself if your application really needs 100 MB of stock images of people using their laptops on the beach or 30 MB of custom sound files. Chances are, it doesn’t.
Seventh : Documentation
We all know how much developers dislike writing documentation. So we tell ourselves that the application is so easy to use, “only an idiot would need a manual.” There are two problems with this thinking. The first is that the world has plenty of idiots in it. The second is that we are usually wrong about how easy the application is to use. If your organization has a technical writer to create the documentation, involve that person from the get-go; the top complaint I hear from technical writers is that they are handed a nearly finished product and told to document it, with little insight into how it actually should be used. If you do not have a technical writer available, you will really need to work hard to make sure that the documentation does not merely state the obvious and is written in a way that will be helpful to end users who are unfamiliar with your application.
Eighth : No surprises
Some applications are filled with surprises. Of course, the definition of a “surprise” is that users don't expect it. But at a higher level, users expect that nothing will come at them from left field, either. This covers a lot of territory. Here are some examples of things your application should not do:
- Require additional payments or service fees (including cell phone minutes for mobile applications) that are not made obvious before the user purchases the software in the first place • Install any advertisement distribution mechanisms
- Add any browser toolbars, Outlook plug-ins, or other “helpful applications or add-ons” to the system
- Delete or modify user data or system files, including libraries
- Send or capture usage data or personal information, for marketing or technical purposes, without the user’s knowledge and consent
- Replace the current default applications for tasks without explicit user confirmation While many users probably won’t notice at least a few of these, and many users won’t raise a big stink about it, it is still wrong. Users don't like it. After all, do you like it when applications behave like this?
Ninth : Easy data backup/restore
Some applications are notorious for being difficult to back up and restore. Some applications hide their data in areas that might not get backed up (especially when the user prepares to move to a new PC or do an OS wipe/reinstall). Microsoft Outlook Express immediately comes to mind, since it buries your mail in the Windows folder instead of user data. (I once lost five years' worth of saved e-mails thanks to this.) Other applications like to lock their data in a way that backup applications can't back them up properly. Make sure that your application puts its data in the appropriate places to allow it to be easily backed up, restored, transferred to a new PC, and so on, and test common backup applications for compatibility with your application, even while it is running, if appropriate.
Tenth : Does what it says it will
I know, this one is just plain silly, right? It makes perfect sense that if an application claims it will do something, that it actually does it. (Doing it well is optional.) At the same time, far too many apps not only fail to meet users' assumptions, but they do not deliver on their explicitly stated promises either. While this may bring up the traditional issues of salespeople and marketing departments promising beyond reality, the simple fact is this: If a user has paid for a particular feature set, you need to deliver that feature set, one way or another. Don’t let your users down by delivering an application that says it does ABC, but only does A and C!
No comments:
Post a Comment