Webforumz Newsletter - December 2007

Articles

See your website through the eyes of a user

Most web designers have heard of usability. Few designers, however, fully appreciate the difficulties faced by users as they attempt to understand a website. In this article I will give a simple example, discuss the connection with accessibility, and exhort you to perform some real-life user testing (with real-life users, no less!).

A usability example: links

Usability relies on convention. By violating conventions, you can damage usability. For example, many websites remove the default underline on links, perhaps reinstating it on hover; this makes links difficult to find. Worse yet, some websites use underlining for headings or emphasis; this frustrates users because they expect the underlined items to be links.

Although you may be a daring and unconventional person, it is a mistake to carry this persona into your web design. By all means wear pyjamas and slippers to the pub, and discourse provocatively on the hypocrisy of the West; but don't make a "radical" website design. Your website is not primarily an expression of your personality: it's a tool for your users.

The best way to ensure users can discover links is to stick to the convention:

  • Links are always underlined.
  • Unvisited links are blue.
  • Visited links are purple.
  • No other text is underlined, blue, or purple.

This won't suit the colour scheme of every website. Yet if you change the colours, you can still follow the other conventions:

  • Links are always underlined and coloured.
  • Visited links are coloured with a duller version of the unvisited link colour (bright red becomes dark red or faded pink, for example).
  • No other text uses these colours, and no other text is underlined.

Failing this, just stick as closely to convention as your design permits. For example, if you can't find any good colours to distinguish visited links from unvisited, then use some other effect to distinguish them, such as a dotted underline on visited links. Although the most usable option is to follow convention exactly, thoughtful deviations from convention will carry little penalty.

(These conventions are for links within the main text. Dedicated navigation bars may follow different conventions.)

How is usability connected to accessibility?

Intimately.

Usability and accessibility are both disciplines whose central premise is to design websites that the widest possible audience can use effectively. Accessibility is a subset of usability: it's about making websites usable for disabled people.

What is disability, anyway?

When you think deeply about disability, you should realise that the world is not divided neatly into disabled and non-disabled people. "Disability" only has meaning relative to social norms, and not everyone whom you perceive as disabled will identify himself as such; not all disabled people wish to define themselves by their disability.

If that seems like rarefied political correctness, think again. When you reach middle-age, if you have not already, you will probably suffer from deteriorating eyesight. But will you have a disability? Objectively, yes: compared to someone in perfect health (whatever that might be!), your eyesight will be inferior. Yet most people who wear glasses don't call themselves "disabled".

Perhaps you think I'm just playing with definitions. Then consider Oscar Pistorius, who is attempting to become the first amputee runner to compete in the Olympic Games. Oscar's application is meeting resistance, because the governing body has claimed he has an unfair advantage over "able-bodied" runners. Oscar can run 100 metres in 10.91 seconds. I bet you can't do that; so who is the disabled person? Oscar himself says: "I don't see myself as disabled. There's nothing I can't do that able-bodied athletes can do."

Accessibility = usability

This is what I'm getting at: the difference between accessibility and usability is like the difference between a partially sighted person (disabled) and a middle-aged person who wears glasses (non-disabled). It's a difference of emphasis, a difference of how you think, a difference of how you perceive.

My friend Ellie, who is blind, uses the screen-reader JAWS. She has it set to read sentences at many times normal speaking speed; it's far too fast for me to understand. Provided a website is well-designed for screen-readers, Ellie can find information much faster than I can. I ask again: which of us is disabled?

Given a sufficiently egalitarian understanding of disability, we can conclude that accessibility and usability are the same thing. The word "accessibility" merely serves to remind you that you must make a special effort to accommodate some users, such as blind people.

This requires a special effort because you are not blind yourself. If you were a blind web designer, then accessibility would be turned on its head: you would need to make a special effort to accommodate sighted users. Blind web designers will have no difficulty making websites work with screen-readers; but sighted users would suddenly feel disabled by a web page devoid of familiar visual aids. The blind users would make fools of the sighted, using screen-readers to jump around the page faster than the eye can follow.

By failing to accommodate blind users in your web design, you create disability for them. If you accommodate them properly, they may out-perform sighted users. Stick that in your pipe and smoke it.

The surprising benefits of user testing

Caring about usability is a good start. Caring and thinking is even better. But to ensure excellent usability, there is no substitute for a real test. You may be surprised by the results.

Self-styled usability guru Jakob Nielsen has been banging on about this for years. Although Nielsen has a vested interest, and although he hardly makes the most attractive poster boy for usability, he is actually correct. I particularly recommend his article, "Why you only need to test with 5 users". To summarise his article:

  • Test with a small group of users (say, five).
  • Fix the problems they find.
  • Then repeat the process.
A real example, with a real user (who has no added sugar)

Even testing with one user is worthwhile. Anyone will do, but not a web designer. I recently asked my dad to test my website; from this simple test, I discovered several usability problems.

When you perform user testing, you must:

  1. Listen to what your users say.
  2. Watch what your users do.
1. Listen to what your users say

My badminton website has a preferences menu, which allows the user to: choose instructions for left-handers or right-handers; choose a skill level (lower skill means simpler instructions); and alter the visual style of the pages. In the original menu, you could change the settings by clicking on links.

My user told me that he found the menu confusing. He expected the links to take him to another page, or at least do something obvious; instead, most of them just quietly changed a setting. He said that he thought they might be broken.

By listening to what he said, I realised that my menu was counter-intuitive. I changed those links to radio buttons instead. The screenshots below show the changes: on the left, the original menu; on the right, the new menu.

In the new menu, you can clearly see the difference between links and selection options. Radio buttons are apt here, because convention dictates that they select a single option from a list. Users will not expect a radio button to take them to a different page.

Notice that the radio button version is longer than the original, because I have made all settings visible at once. This is a usability improvement for two reasons:

  • It removes ambiguity. In the original menu, does "low-glare colours" mean "the current state is low-glare colours", or does it mean "this link will activate low-glare colours"?
  • It shows users a full list of their options.

I enclosed the radio <input>s and text within a <label>, like this:


<label for="skill1Label"><input id="skill1Label" name="skillRadio" 
type="radio">Beginner</label>

Adding the <label> associates the radio button with the text; this provides a much larger target, because the user can click the text as well as the radio button. Including the "for" attribute should not be necessary, but IE6 requires this explicit association. To help users realise they can click the text, I styled the <label> with the CSS { cursor: pointer }, replicating the cursor appearance of a link (see the W3schools explanation of CSS cursors).

So far, so good; I'm feeling pleased with myself. But it's not over yet.

2. Watch what your users do

As my user explored the menu, he clicked on the "what does this do?" link (this was a real link). This took him to the relevant section of my help page, so that the content was immediately scrolled to the appropriate place. What behaviour could be more benign?

Linking to internal page anchors (that is, linking to somePage.html#someElementID) has the advantage of cutting straight to the relevant information. Unfortunately, it also disorients users. Because they don't see the top part of the page, they don't know where they are. I knew this already, but I had judged that the disadvantage was trivial.

Not so. I fidgeted in my chair, eager to take over, as my user painstakingly carried out the following process:

  • He read the explanation, and seemed satisfied. Good.
  • He scrolled down the page a bit, hesitantly.
  • He scrolled back to where he started.
  • He paused.
  • He scrolled down again.
  • He scrolled up to the top of the page. Only now does he realise his location.
  • He hesitated even longer. His mouse pointer wandered uncertainly around the top area of the page.
  • Ignoring the back button, and ignoring my large "Home" link, he found my breadcrumb navigation and clicked "Home".

At this point, you may be tempted to dismiss my user as an idiot, or as hopeless with computers. That would be a gross error. This particular user has an I.Q. of at least 140, and is highly computer-savvy, having been personally responsible for the I.T. infrastructure of one of the world's largest companies.

If this is how he behaves, God help the average user.

Perhaps now you are beginning to understand how severe the challenge is. Web designers are pathologically blind to the reality of user behaviour; there is no substitute for watching a user. In this example, we've seen how the apparently innocent act of jumping to an internal page anchor can cause disorientation. Now it's time to make some excuses:

  • "My user should have done ... instead; you see, it's really very simple."
  • "You'll always get some users who don't understand. I'm sure most people would have no trouble with my design."
  • "Okay, I recognise it's not perfect. But what else can I do?"

Indulge yourself in the excuses; feel their comforting softness; and then renounce them! The most reasonable excuse is the last one; but I never said improving usability was easy.

To fix the problem, I place the help information where it's needed: on the same page. Although it's convenient for me to link to my help page, it's not convenient for my users. In the source code, this information appears directly after the menu; but I hide it with CSS, and when the link is clicked I use absolute positioning to make it appear alongside the menu, like so:

I've also changed the colour of the help links, changed their underline from solid to dotted, and applied the CSS { cursor: help }. The purpose of this is to give visual clues that these are special pop-up help links; I'm trying to make their behaviour less surprising.

Unfortunately there are no clear conventions for this (unlike the radio buttons), so it's not an ideal solution; but it's better than nothing. Solving usability problems is not always trivial; there isn't always an obvious, perfect solution. Even Nielsen, provocative merchant-king of the field, admits he regularly makes usability errors.

Conclusions

User testing is the most effective way to improve usability. All websites can benefit from this; you don't need many users, and you can do it for free.

Listen to what your users say; it may provide useful insights. More importantly, however, watch what your users do; because it is what users do, not what they say, that gives you direct understanding of their behaviour.

Since disabled people are users too, the same principles apply to "accessibility testing"; it's just user testing under a different name. If you're lucky enough to have a blind friend, ask him to test your website; listen to what he says, and observe what he does (though you might be unable to keep up with his screen-reader. That's your disability; ask him for some assistance).

While you're recovering from the shock of user testing, take a coffee break and wheel out the usual excuses. Wallow in them for a few minutes. Reflect that users are the last people who should be allowed near websites, since they are evidently incompetent.

Then wash out your coffee cup, take a deep breath, and go fix your website.