When Web pages don't work

Steps you can take to improve the user experience on the Web

Puzzled why your site is not living up to your expectations? The problem may not lie with your content or products, but rather in your site's user experience. Find out what common pitfalls to avoid by following a few simple guidelines to improve the user experience and transform surfers into customers.


Chris Paul (chrispaul@mindspring.com), Creative Director, IBM WebSphere Web Analytics UI Design and Development

Chris Paul is the Creative Director and Manager of the IBM Web Analytics UI Design and Development group, an eclectic blend of artists, designers, and programmers. He was previously the lead UI designer on WebSphere Studio. He holds an M.F.A. in Graphic Design from the Yale School of Art, where he did his thesis work on user-interface design. In his spare time he likes to abandon all modern technology and cast lead type and print letterpress. You can contact him at chrispaul@mindspring.com

09 February 2005

As the Net rapidly evolves away from the grand library ideals of its inception, those responsible for the design and implementation of Web-based e-commerce solutions face new challenges. It's not enough to deploy the latest Web technologies, or host on the fastest servers. If you want to sustain your Web-based business, you'll need to take a close look at the user experience. While user experience isn't the holy grail of Web design, when applied intelligently, it can increase customer satisfaction, facilitate purchasing, and drive that ever-important repeat business.

User experience on the Web can be loosely defined as the sum total of a user's satisfaction with your site. As Jakob Nielsen says, system usability, which is closely related to user experience, "has many components, including ease of learning, efficiency of use, memorability, reduced number of user errors, and subjective satisfaction."

Are you user-experienced?

How many times have you been to a site that you just couldn't get your head around? Maybe the navigation was confusing. Or maybe you were just left with an unsettled feeling that something wasn't quite right. Chances are you haven't returned to that site. There's an even better chance that if that site was selling something, you didn't buy it.

User experience is not a new concept. The brick-and-mortar retailing industry has known about it for years. In many ways, positive user experience is a lot like good, old-fashioned customer service. The kind of customer service you'd expect from any of the big retailing chains: pleasant and knowledgeable sales people, clean show rooms, good selection, and stocked inventories. The biggest difference with the Web, however, is that your competitors aren't across town any more; they're just a couple of mouse clicks away.

How can you tell if your site is suffering from poor user experience?

It's not easy to determine if your site problems are the result of poor user experience. As you know, many factors can negatively affect site traffic. You could have the best site on the Net, but without a solid promotional effort, surfers may never find it. Some of the most reliable signs of poor user experience manifest themselves in your traffic and activity logs. These include:

  • Lots of traffic, few purchases
  • Abandoned items in shopping carts
  • Visitors only hitting the top level of your site -- not deeper pages
  • Lack of repeat customers

If you notice any of these trends in your traffic analysis, maybe it's time to re-evaluate your site from a user perspective. Your first activity, on your way to user experience salvation, is to determine if you've committed any of the Prime Evils of user-experience design.

The first Prime Evil: Confusing navigation and unexpected behavior

Too often, sites are constructed with flawed or inconsistent navigational models. The first page users see when they enter your site establishes expectations as to how they can navigate your site. You may have an area of your home page reserved for primary navigation; that is, the main pages of your site. Many sites have a secondary navigational area whose content changes based on the primary navigation choice.

By strictly maintaining these reserved navigational areas, you provide your visitors with a comfort level and a sense of place. That is, the users are aware of their relative position in your site and can anticipate how to navigate to other areas of interest. Not being able to tell where they are, how they got there, or how to get out feels uncomfortable. Be kind to your visitors -- don't take them into unfamiliar territory without leaving them a bread-crumb trail.

This Prime Evil can also manifest itself in unexpected behaviors and interactions on a site. Just as every operating system (OS) has conventions that enable users to navigate the desktop and organize their work, the Web has a similar vocabulary of expectation. The best way to understand the importance of consistent behaviors on the Web is to become conscious of the interaction conventions applied in your favorite OS. The simplest example is the file-and-folder paradigm of the Windows and Macintosh operating systems. You know that files can be contained inside of folders. You know that by double-clicking a folder, you can open it and view its files.

We become accustomed to even more subtle conventions in tools we use frequently: Windows almost always places the Cancel button on the lower right corner of its dialogs. We never really notice this convention except when it's broken, and by then it is usually too late. You'll go to hit Cancel -- moving your mouse to the lower-right corner and clicking... Typically this action is automatic, almost instinctive. Imagine the trouble that would be created if all the Cancel buttons were suddenly changed into OK buttons, and vice versa. Or worse yet, if all the Cancel buttons suddenly transformed into Save buttons! There would be chaos, not to mention some very frustrated users.

You must construct your site in such a way as to take advantage of what people already know about the Web. Just as good desktop software developers adhere to well-defined standards for their platforms, Web developers must do the same for the standards of the Web. The Web has already built up a robust vocabulary of conventions and expectations. Users should be able to easily tell what is a link and what is not. They should be able to hit the Back button and get the expected behavior of returning to the page they had just left. When they click something, they should receive some sort of feedback.

These aren't divine revelations, but there are thousands of pages out there that ignore even these basic tenets. Imagine having to write software in a world in which no conventions existed, and each and every click of the mouse had to be taught to the user. I'm glad conventions have already been established; our work is hard enough without having to invent new ways to show links, save files, or close windows.

The second Prime Evil: Slow response time

Yes, you knew it was coming. I'm sure you're probably tired of hearing about this one, so I'll make it short. Sure, bandwidth keeps increasing and more folks are hooking up cable modems. The general public, however, is still dialing in at 56 kbps. Some folks do still dial in at 28.8 kbps (probably cave dwellers)! Even if someone has a high-speed modem, numerous factors can slow down connect speed. For example, I rarely get above 48 kbps on my 56 kbps modem. Keep this in mind as you sit behind your super-charged, turbo-speed rocket box with a T1 line pumping content into it. The gap between the capabilities of the equipment you develop on and the capabilities of the equipment the general public uses to access your site is widening. The best way to sidestep this Prime Evil is to do a little testing on the lowest-common-denominator system for your target audience.

It is easy to become jaded by the response time of your machine. As a general rule, response time that you can barely tolerate probably isn't acceptable at all for your users. With all the choices out there for your users, you only have a few seconds to score customers. If your site doesn't load quickly enough or appears to be sluggish, users will move on to the next URL from the search-engine results page.

To get inside your users' heads, be sure to view your published site with different dial-up speeds. It sounds crazy, but I keep a 28.8 kbps external modem around just for this purpose. Sure, you can calculate the download speed, but nothing beats the experience of sitting there waiting for a page to load.

How do you improve the speed of your download? Start with the obvious: Make sure to optimize your images for Web display. A bunch of good utilities out there can handle that task. Also, if you use a certain GIF file over and over again in your page -- such as a transparent spacer GIF -- load it by itself as the first item in the HTML (JavaScript is good for doing that without messing up the page layout). This gets the oft-used GIF into the cache right away and prevents the client from having to fetch it from the server again and again.

You can find a hundred other tips to speed the response time of your site. The bottom line is: Ignore download time only if you don't care about traffic and repeat customers.

The third Prime Evil: Depending on bleeding-edge technology

Using bleeding-edge technology on your site is closely tied to the sluggish downloading Evil. It may be fun and helps keep your resume current, but it does little to attract and maintain customers. I was shocked when I first saw some traffic stats for a site I was working on recently. Some people (must be those cave dwellers again) were hitting the site with Internet Explorer 3.01! Surely, I'd thought, everyone was just like me -- as soon as the first alpha, unsupported, preview-only version of the next generation browser hits the streets, they download and install it. How could people actually have a good experience viewing my site on IE 3.01? The answer is, of course, they can't.

This realization brings us back to the old user-interface design motto: know thy user. Generally speaking, it's only the techheads like us who rush out to upgrade our browsers three to four times a year with the latest plug-ins and rendering engines. I've heard a lot of users repeat the saying, "If it ain't broke, don't fix it." Some people have a hard enough time trying to get something to print from their computers, let alone bothering to upgrade their browsers. If you're reading this, you probably spend your days immersed in this technology. What is familiar and comfortable to you may not be so cozy for your clientele.

I've seen a lot of sites try to get around these technology dependencies with initial pages that warn users to not even enter a site unless they have a particular browser level with yet another specific plug-in. That's like putting a sign out in front of your shop that says: "Only people born in May can enter." Sure, there may be thousands of people born in May walking by your door, but you're missing out on some big numbers by excluding the other 11 months. In addition, those people born in December whom you are excluding are not going to develop warm fuzzies about your company.

So plan for the lowest common denominator. This doesn't mean your site has to be boring or you have to take down the Flash movie you put up yesterday. Just give your technology-challenged visitors some relief. It is OK to reward the brave souls out there with all the latest accessories with extra cool stuff that only they can see, just default to the stuff everyone can see and show the glitzy stuff on demand. You can also use JavaScript routines to detect a particular plug-in or browser level you are relying on and provide an alternative if you don't find what you're looking for. In fact, it's a good idea to use these routines in any case, because some users may not know they have the appropriate capability you require and will pass on by without even trying.

The fourth Prime Evil: Not conducting user testing

The Prime Evils at a glance

Need a summary of user design Prime Evils to avoid, one that will fit on a sticky note? Here are the five Evils. Ignore them at your peril.

  • Confusing navigation and/or unexpected behaviors
  • Slow response time
  • Bleeding-edge technologies
  • Poor (or omitted) user testing
  • Off-the-cuff design services instead of professional user design

This one is fairly self-explanatory. You shouldn't be putting anything out there on the Web that hasn't gone through some level of user-testing. The goal of your user testing is four-fold:

  • Validate your design decisions
  • Obtain feedback from users
  • Ascertain your competitiveness
  • Save yourself massive embarrassment (and perhaps your job)

You don't have to go over the top with this. Bring in a few users, feed them pizza, and watch them play around with your site for a couple of hours. Pay careful attention to what they are doing and ask them to voice their thoughts out loud as they peruse your site. You'll want to have a few specific tasks outlined for them to complete. For instance: Identify and purchase a blue widget; register for more information; find the technical support phone number. The particular goals of your site will help you decide what tasks to test.

User-test your competitors' sites as well, and ask your users to compare and contrast. This will help you gain valuable insight into what the users feel is most important. After the testing, debrief the users on their experiences and ask them to summarize their main likes and dislikes. The trick to user testing is to try to get at the root cause of a particular user comment. For example, if users say they'd like a button in a particular place on the screen, this doesn't mean you should go and add one there. Find out why they want a button there and what they expect it to do. Often it is the things that users don't immediately volunteer that is most important: "I want a button there because I'm not confident this info will be saved when I move on."

Of course, by bringing people into a test lab, you are taking them out of their own environment, and as I discussed in the second Prime Evil, away from their own equipment. So it's a good idea to also set up some testing that can be done by users in their homes or places of work, on their own time. Since you won't be there to ask questions, you need to put together a fairly detailed questionnaire -- but that's another topic.

The fifth Prime Evil: Lack of professional design services

You may be good at writing code, but are you the right person to be designing the user-experience? Chances are, you're probably not. Besides, you're under enough pressure trying to make the code rock solid. The best bet to avoid this fifth Prime Evil, and the others, is to employ the services of a good specialized Web designer early in the process. Don't make the all-too-common mistake of bringing such a person in only at the end of the process.

Good design entails much more than aesthetics. You can have the best-looking site out there, but if users can't navigate it, they won't come back. User experience designers come in many flavors and are sometimes called information architects, UI (user interface) designers, HCI (human-computer interface) engineers, and often a few other choice names. In my experience, the people who are really good at writing the code that makes the Web work and the folks who are good at keeping the interactions simple and predictable are wired differently. I couldn't begin to architect the kind of code that makes some of the more sophisticated sites on the Net run. My synapses just don't fire in that way.

By the same token, most of the really good developers I know -- the ones who dream in code -- can't figure out what a user really wants to do, or how to help them get from point A to point B. They know how to give the user every option imaginable but not how to guide them and promote a positive experience. Just as it takes a team of people with different skills to build a house, so, too, does it take a team to build a successful Web site. You need writers and editors to produce the content, artists and designers to create the art, developers to architect and write the code, and user-experience designers to craft the experience.

Too often managers assume that these roles are seemingly interchangeable. The person making your banner and other Web art may not be the best choice for also designing your user experience. While many talented people can successfully work in both disciplines, you may not always find both sets of skills in the same person. User-experience design and user-interface design together form a specialized discipline that requires training and experience. I've met tons of talented graphic designers over the years, yet only a handful of really good user-interface designers.


User-experience design will continue to play an increasingly important role in attracting and maintaining customers on the Web. It is not enough to attract surfers to your site. To transform surfers into purchasers, your site must be easy to navigate, predictable, and quick. Although successful user-experience design is not the only factor in effective Web commerce, it is a critical component that can make or break your site. It pays to pay attention to what your users experience. Your competition does.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Web development on developerWorks

Zone=Web development
ArticleTitle=When Web pages don't work