10 ways developers can meet user expectations and ease frustrations
A long time ago, when people went to stores to purchase software in boxes, it was common to have to spend 15minutes studying the box to determine whether it would run on your system. Now, as long as the application runson 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 onthe supposedly platform-independent Internet. With the exception of some “must-have” enterprise classapplication, there is no way that a user or organization is going to jump through hoops to make your applicationrun or your Web site work.So instead of driving away potential users, find and fix the incompatibilities. Obviously, that doesn’t mean that aWindows application needs to be made to run on Linux; but it does mean that a Windows application should workon XP, Vista, the upcoming Windows 7, and possibly even 2000. Likewise, your Web applications should work onInternet Explorer, Firefox, Opera, Safari, and Chrome across OSes without a loss of functionality or significantdifferences in appearance.
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 asimple text editor should require 1 GB of RAM to run. Yet it seems that more and more applications are hugeresource hogs. It seems like every minor application out there is nearly as large as Microsoft Office was five yearsago... and Microsoft Office itself is now the size that an operating system was a few years ago! Users expectbetter, and so should you. Cut the bloat. Ask yourself if your application really needs 100 MB of stock images ofpeople using their laptops on the beach or 30 MB of custom sound files. Chances are, it doesn’t.
We all know how much developers dislike writing documentation. So we tell ourselves that the application is soeasy to use, “only an idiot would need a manual.” There are two problems with this thinking. The first is that theworld has plenty of idiots in it. The second is that we are usually wrong about how easy the application is to use. Ifyour organization has a technical writer to create the documentation, involve that person from the get-go; the topcomplaint 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 reallyneed to work hard to make sure that the documentation does not merely state the obvious and is written in a waythat will be helpful to end users who are unfamiliar with your application.
Some applications are filled with surprises. Of course, the definition of a “surprise” is that users don't expect it. Butat 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) thatare not made obvious
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 theuser’s knowledge and consent
Replace the current default applications for tasks without explicit user confirmationWhile many users probably won’t notice at least a few of these, and many users won’t raise a big stink about it, itis still wrong. Users don't like it. After all, do you like it when applications behave like this?
Page 2Copyright © 2008 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, IncFor more downloads and a free TechRepublic membership, please visithttp://techrepublic.com.com/2001-6240-0.html