Found this article on Tech Republic while browsing my junk mail just now, and found that this is not junk at all ..... :
Would you want your brakes installed by someone who is on their first day on the job with no training and expects fixing brakes to be intuitive? I didn’t think so. But this is essentially the expectation that we have been perpetrating in this industry for years now.
Somewhere along the way we lost track of the fact that software is often used to accomplish some very complex tasks. As a result, this expectation has turned into a curse. Users now feel entitled to sit in front of any given piece of software and instantly understand its every nook and cranny. And if they can’t, it’s the software developer’s fault for not making intuitive software. This is an unrealistic expectation, and it’s time to start reversing the trend. Below I present what I perceive to be the problems that have perpetuated the myth of intuitive software, as well some potential solutions.
The problems
The first part of the problem is the idea that users who have no experience or understanding of the field of knowledge the software addresses should be able to use the software. If I sat in the cockpit of a 747, I would not expect to be able to fly it after glancing at the controls (even if I did put in countless hours of Wing Commander), yet this is the first mistake users make when blaming the software developer. “I don’t know what it means when it asks me to enter my IP address, so this software is hard to use.” Would users prefer for the software to ask for their system administrator’s e-mail address, and then automatically e-mail that person and ask them to reply with the IP address? Or, would the user want the software to provide a short tutorial on networking? If the user does not understand what an IP address is, no application should be teaching it to them; the software should be looking for a way to get the information without the user’s help.
The next part of the problem is that even users who are knowledgeable in the problem domain are not necessarily going to “get” a piece of software if the domain is sufficiently complex. Word processors are a great example. A word processor is a piece of software designed to do hundreds of tasks — everything from writing grocery lists to legal briefs to screenplays, all of which have different workflow requirements, formatting needs, and so on. Needless to say, any piece of software designed to do not just one complex task but hundreds of complex tasks is going to be complex. Given the complexity of these pieces of software, why would we expect someone who is good at writing essays out by hand to instantly “get” a word processor right away?
ERP and CRM applications are some of the favorite punching bags in the industry. It is common knowledge that a huge number (some studies show the majority) of licenses sold for applications like SAP go unused. These projects have an astoundingly high failure rate, and when you consider their sticker price, that is really unacceptable. One of the typical causes for a project to be declared a failure is that it is “dustware.” That is, after a year-long integration and millions of dollars in consulting fees and license costs, the users fire it up, stare at the screen for five minutes, shut it down, and it sits on the shelf for eternity. Well, not to give these enterprise-class vendors a free pass, but I do not think that plopping a user in front of a complex piece of software untrained and with no documentation is a good way to get them to use it. If I expect a crane operator to be trained in that piece of equipment before using it to lift 10 tons of steel, I think it’s reasonable to think that someone should be trained before using a piece of complex software.
What is most frustrating to me is that things were not always this way (at least, that’s my recollection). WordPerfect 5.1, which is often remembered with a mixture of fondness and disdain, required you to purchase a keyboard overlay, a 100 - 200 page Quick Reference guide, and have a 500 page in-depth manual on your desk to be well-equipped to use it. But the simple fact was, you really needed to read a few hundred pages of text to get the gist of what was happening before you could sit down and do real work. That was also an era when there were local users’ groups for users to get together and help each other out. In addition, companies also sent their employees to computer training.
Now employers are looking for computer savvy and computer literate employees, which seem to mean, “I can use Google to find Gmail.” Instead of teaching true computing skills, such as how to form effective search queries, how to discern which Web sites are credible, and how to maintain security of private data, schools are letting students play on Facebook and LiveJournal, and saying, “Oh, the kids are learning how to use a computer.” Nonsense. The students are learning, at best, how to use a particular Web site that will be different by the time they graduate.
Proposed solutions
Our industry needs to do more about this issue. Sure, we occasionally throw our hands in the air and spew forth a loud “RTFM!” Which would help if “TFM” wasn’t often so useless. After all, why bother writing good documentation when the only people who care to read it are those who can figure it out on their own? It’s a catch-22. So first up is the documentation. If your application is addressing complex tasks, you can’t count on an intuitive interface.
A complex task will require either a ton of walk-through style wizards (which power users hate and even beginners eventually outgrow); or an interface like a command line; or a toolbar crammed with buttons, lots of keyboard shortcuts, or some other way of packing a lot of functionality into a small screen space. And with interfaces like that, the documentation needs to be better. Unlike a wizard-driven interface, you do not have a paragraph to explain each choice; at best, you have a tooltip to explain what function the icon represents. Users in these situations need to be able to rely upon the documentation to give them in-depth information.
A fallacy is that in order for software to be intuitive, it needs to be different from the “hard to use” products on the market. Networking devices are a good example. If I were to market a networking device, I would do my best to emulate the Cisco IOS to the most minor detail. Even though the Cisco IOS is not intuitive (in fact, it is one of the most consistently miserable pieces of software I have ever dealt with), nearly every network administrator has spent a lot of time learning the intricacies of IOS. By emulating a really obnoxious system, you are actually working with existing user knowledge. You see this a lot in the *Nix world. Because so much of *Nix counts on pipes and redirects, applications tend to implement the I/O patterns of existing applications in order to be a drop-in replacement, even if they support their own (and probably better) I/O as well. If you are trying to break into an existing market, you will want to provide a UI that looks like the current king, even if you have a better one as an alternative. If possible, try to use both, with an easy way of switching between the two.
We also need to stop counting on the community to provide support for us. A huge temptation, particularly in the current economic climate, is to put some freeware wiki or forum software on a server, link to it from the Support section of the Web site, and expect that users will train each other. I am not saying this doesn’t happen or telling you not to set up a wiki or a forum. I’m saying that even with these tools, your staff will need to spend a lot of time on the wiki or forum and provide many (if not most) of the answers — at least until you get a number of MVPs on board and editing the wiki.
Also, I would like to see more new user and experienced user modes for software, particularly in super-complex applications. It would be even better if the software could seamlessly transition on a feature-by-feature basis. For example, once a user does Task A a few times without too much help, the software stops using wizards, but the first time a user does Task B, the software still has him in training wheels mode. I think this would be a great way to combine the promises of agent-based systems with the guidance of wizards and hands-on tutorials.
Finally, let’s get honest and drop the “easy to use” bullet point in our marketing materials when possible. Instead, we need to start putting in good tutorials and have our sales reps offer free (or highly discounted) training. What do you think costs your company more money: sending a trainer on site for a week to get new users up to speed, or not having a customer renew its license because no one ever used the system and then bad-mouth your software to boot? In the long run, it makes more sense to give free (or highly discounted) on-site training to big accounts and free online training to smaller accounts than it does to lose the upgrade fees.
In conclusion, software does not need to be intuitive to users who don’t know the field; and even for users who understand the work, complex tasks are going to have complex software. But, software developers need to keep finding ways to make sure that users get up to speed and can fly on their own.
J.Ja
Disclosure of Justin’s industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.
