11/04/12 When Web pages don't work

English Sign in (or register)

Technical topics Evaluation software Community Events

When Web pages don't work

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

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

Summary: 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.

Date: 09 Feb 2005

Level: Introductory

Comments: 0 (View | Add comment ­ Sign in)

Average rating (38 votes)

Rate this article

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.

www.ibm.com/developerworks/web/library/web-work/index.html 1/6
11/04/12 When Web pages don't work

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

www.ibm.com/developerworks/web/library/web-work/index.html 2/6
11/04/12 When Web pages don't work

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.

www.ibm.com/developerworks/web/library/web-work/index.html 3/6
11/04/12 When Web pages don't work

Finally...

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.

Resources

Jakob Nielsen is the guru of Web page usability. His site useit.com includes Alertbox, a biweekly column on Web usability and user­interface
design.

The IBM Ease of Use Web site contains many valuable resources and links.

Isys Information Architect's Web site includes an Interface Hall of Shame and Interface Hall of Fame.

Vincent Flander's Web Pages That Suck includes a tour of some of the most annoying and irresponsible site features. Stop in and see how your site
rates.

Bruce Tognazzini's Ask Tog site features hints and tips for Web application interface design as well as some more general articles on the lighter side
of UI design.

Get a copy of Jakob Nielsen's new book, Designing Web Usability.

Alan Cooper's book, About Face: The Essentials of User Interface Design is an excellent resource.

Kevin Mullet and Darrell Sano have created another great resource in Designing Visual Interfaces: Communication Oriented Techniques.

About the author

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

Close [x]

developerWorks: Sign in
If you don't have an IBM ID and password, register here.

IBM ID:
Forgot your IBM ID?

Password:
Forgot your password?
Change your password

After sign in: Stay on the current page

Keep me signed in.

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

Submit Cancel

The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified
when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the
information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

www.ibm.com/developerworks/web/library/web-work/index.html 4/6
11/04/12 When Web pages don't work

Close [x]

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.

Display name: (Must be between 3 – 31 characters.)

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

Submit Cancel

All information submitted is secure.

Average rating (38 votes)

1 star 1 star
2 stars 2 stars
3 stars 3 stars
4 stars 4 stars
5 stars 5 stars

Submit

Add comment:

Sign in or register to leave a comment.

Note: HTML elements are not supported within comments.

Notify me when a comment is added1000 characters left

Post

Be the first to add a comment

Print this page Share this page Follow developerWorks

Technical topics Evaluation software Community About developerWorks IBM

AIX and UNIX Java technology By IBM product Forums Site help and feedback Solutions
IBM i Linux By evaluation method Groups Contacts Software
Information Open source By industry Blogs Article submissions Software services
Management
SOA and web services Wikis Support
Lotus Events Related resources
Web development Terms of use Product information
Rational Briefings Students and faculty
XML Report abuse Redbooks
Tivoli Webcasts Business Partners
More... Privacy
WebSphere Find events IBM Champion

www.ibm.com/developerworks/web/library/web-work/index.html 5/6
11/04/12 When Web pages don't work

program Accessibility
Cloud computing More...
Industries

Integrated Service
Management

www.ibm.com/developerworks/web/library/web-work/index.html 6/6