Many e-commerce websites and Web information services exhibit an astounding lack of "common sense" about the domain they are supposed to cover. You ask them to do something, and they respond in a way that no person, no matter how uneducated or new to the job, would respond. In such cases, the problem is usually that the databases comprising the "back end" of the service are missing important, "task-focused" data. Bluntly, the back-end wasn't designed to support user tasks. If a Web service has this problem, it doesn't matter how "easy-to-use" the front end is: the overall user experience will still frustrate users and limit their productivity.
Online reservation systems of major airlines allow customers to book flights over the Web, but many lack information about cities and towns that don't have commercial air service. I"m talking about towns like New Haven, CT (USA); Paderborn (Germany); or Sienna (Italy). If you try to book a flight to such a place, many airline websites simply say they don't fly there and can't help you. In contrast, a human reservation agent would immediately -- without even asking you -- assume you want to fly to the nearest major airport and take ground transportation from there to your destination.
For instance, I had to travel recently to Ann Arbor, Michigan. I knew that major airlines don't fly into Ann Arbor, but wasn't sure what major airport is nearest. Any human ticket agent knows that Detroit (DTW) serves as Ann Arbor's airport. I gave "Ann Arbor" as my destination. Some airline websites (e.g., United) automatically assume Detroit, but many do not. Continental Airlines' website told me: "Ann Arbor is not currently served by Continental or its partners" (see below). Similarly, Northwest Airlines' site said: "No Northwest ... flights were found ... between San Francisco (SFO-San Francisco Intl.) ... and Ann Arbor, MI (ARB) that matched your request", even though Detroit is one of Northwest's hubs.
Airlines aren't the only companies with frustratingly ignorant websites. Greyhound Bus Company's site shows clearly that an easy-to-use front-end cannot make up for a back-end designed without regard to actual user tasks. The site accepts only the locations of Greyhound bus stations as departure and arrival points. Furthermore, it provides no help in figuring out what stations are nearest to your starting and ending locations. You have to know where the bus stations are. You do, don't you?
However, it's even worse than that. Let's say you go to Greyhound.com's ticket-center page and type-in that you wish to travel from Fremont, California to Torrance, California (see below). Greyhound has no stations in those towns, so it substitutes the closest towns that have stations. The problem is, "closest" means alphabetically. Fresno is substituted for Fremont, Tehachapi for Torrance. In fact, Fresno is nowhere near Fremont, and Tehachapi is about 90 miles from Torrance. It is hard to imagine anything less useful.
Developers can't just slap a front-end -- no matter how easy it is to use -- onto a non-task-focused back-end and expect to have a usable and useful Web service. They have to design the entire system -- back-end as well as front-end -- to support users and their tasks. Furthermore, they have to test the service on representative users early and often during development to check that it really supports users tasks and doesn't exhibit any blatant common sense bloopers.
It can be done. As mentioned earlier, in contrast to several other airlines, United Airlines' online booking service accepts towns that lack major commercial airports. Like human travel agents, United.com distinguishes between a customers' final destination and the destination airport. When given Ann Arbor, Michigan as a destination, it simply assumes Detroit DTW as the destination airport (see below). The difference here is in United.com's back-end servers, not its front-end site.