Abstract
Web usability covers the organization of the content (structure) of the site and its individual pages, navigation through the site, the text used to label the structure and navigation, user interaction through forms, and the structure, layout, and wording of text content. In most cases, recognizing the structure of the content and minimizing the effort to find and use content are enough to make for good “usability”.
Introduction
I mostly agree with Jakob Nielson on web usability issues. In particular, I appreciate that his book is subtitled: “the practice of simplicity”. In my opinion, most usability issues come down to making it as simple as possible to do whatever tasks users have in mind. Since we build the websites, we have a good idea what users will want to do on them.
In fact, the first thing users will usually do is hunt for content. We should make the hunt as easy as possible. After the hunt, users either read/view/listen, compare, or transact. When reading (etc.) we should reduce distractions and avoid wasting the users’ time. For transactions, we should make the process easy to understand, and avoid wasting time.
In all of this we face three types of constraints: cognitive limitations, attention, and technical.
Cognitive limits are a function of human evolution. Our “short-term memory” will only hold about four “chunks” of information. (“Seven, plus or minus two” is, empirically, false.) We deal with only being able to handle four chunks of information by recognizing patterns and decomposing hierarchically.
For example, when we look at web pages, we break them into a few major parts. Users have been trained to ignore the area above navigation that typically contains banner ads (and also branding). Users quickly identify the part of a page that is “content”, and various more or less useful parts of the page that are devoted to navigation. The message is to make it easy to distinguish the various parts of a page. When a user focuses in on one part, it should be easy to tell the difference between the links, and easy to tell what you get if you click on the link.
On the web, we face a serious attention/retention problem. If a page is too boring, too confusing, or too time-wasting – the whole web is only a click away – people leave. People have better things to do than waste time on broken websites. If you want to win in this game, make life easy and welcoming for the user.
This reduced patience/attention-span also shows up in the way people “scan” pages as opposed to “reading”. Often this is scanning to find a link to the information they want. Sometimes it is scanning the page to see if it is really the content they want. Sometimes it is scanning the page for a particular piece of information. Sometimes it’s just scanning the page to get the highlights without taking the time to read. You can, of course, put content on the web that must be read like a novel – one word at a time, linearly – but fewer people will choose to read it than if it is easy to scan. Improve “scanning” by using more headlines, more lists, blank lines between paragraphs, and putting key links on separate lines (not in the text of the paragraph).
And of course there are serious technical constraints inherent in using browsers and internet connections, and especially in not controlling the software used to display the site. In fact, this limits what is possible to do. I contend that if your site is of any practical value, it should be accessible to all devices and bandwidths.
There are, in fact, two areas where I disagree with Nielson.
He tends to emphasize that a webpage should work for all browsers. I, however, am perfectly willing to allow for several html files to exist on a server with the same content, but optimized for different browsers. Doing this would solve many of the web’s problems. (The various versions must share the same url, so that when search engines index the page, they use a url that will allow everyone appropriate access to the information.)
Nielson also ignores the usability aspect of typography. He argues for making websites that will expand in width to whatever size window a user has. But we know from extensive typographic research that there is a length of line beyond which people have a more difficult time reading. I feel no compunction to allow people to make it difficult for themselves to read my website. Note, however, that I would still have a version of a site that would not constrain line lengths. Robots don’t need page layout, and some people may want to use very large fonts for accessibility.
Testing
I also follow Nielson’s take on usability testing.
My story is that you have to be smart enough to know what to test for. If you’re smart enough to test for it, you would have designed “it” right to begin with. Buy good design, not good testing. The exception is to prove that a bad idea doesn’t work. Then, by all means reserve a large budget for usability testing so that you can empirically verify what is already obvious.
Nielson suggests using about five testers. This is roughly the equivalent of getting someone else to proofread an essay you’ve written: after a certain point you will miss things, just because you have been so wrapped up in the project. Watching a few people use your site will wake you up.
I like Nielson’s notion of heuristic testing, in which you have experienced web builders go through a site with a list of points to check.
Also, keep detailed logs on the website – enough to link each hit to an individual browser – and study the logs. Also log the text people search for, and the number of pages each search finds. Make sure people are getting results that match what they're looking for. If not, tweak the search engine and/or the metadata and content.
I would certainly do extensive log analysis before spending money on usability testing (beyond the “five user” style test).
Obviously quality assurance....
Usability, obviously, shouldn’t be confused with quality assurance. User testing, for example, is far too expensive a way to find bugs.
Many of the worst bugs in websites are the result of lack of consideration for the variety of browsers and other “user agents”. An “access” mindset will prevent a lot of bugs, including a lot of bugs that might wind up as usability issues.
Basics
The first thing is that a website loads fast, doesn’t crash the browsers, and works on all browsers. (Can people read the text?)
The second thing is to indicate what can be done at the website, to try to give a sense of the scope and scale. This is quite a trick with only a few pixels. Good websites succeed at this.
The third thing is that for any link, the user should easily guess what will be on the page. Then, arriving at the page, it should be obvious that the user got the expected page. It should be obvious where the page is in the structure of the site.
The fourth thing is always to minimize the cognitive effort, time, and attention required to accomplish any task. This isn’t to say you can’t humanize a site a little. It is to say that “no one cares about your dumb design”. Just make it easy for users to do what they want to do and then get on with their lives.
The fifth thing is vocabulary in the hunt. Search engines will only work if the user is familiar enough to use your vocabulary (and is good at using search engines). Drill-down (a la Yahoo) works if the user can recognize the distinctions in your vocabulary, even if they can’t articulate the distinctions. An index allows you to include words and phrases that you believe are in the users’ vocabulary. A good search engine is difficult to integrate, but has very little ongoing content integration cost. Yahoo-like categorization and indexing schemes are valuable when used, but can be expensive to maintain, as each new piece of content needs to be located in the hierarchy and needs its own index tokens.
For commercial sites, maybe this should be the first thing: be on the users’ side. Don’t waste their time. Don’t force them to jump through dumb hoops. Winning sites will be easiest/fastest/friendliest to use. For example, if you demand too much personal information too early in the process, users will just go to a different website.
As for transactions, html’s set of ‘widgets’ is very limited. There’s not much room to screw up. The important thing is to have good labels for the fields, so users easily understand what they should type. Indicate if a field is required. Intrusive Javascript field-level validation is almost always irritating. I’d say give users full control over the form until they submit. Reduce the number of pages required to complete the transaction. On the other hand, there are cases of dependencies between fields. Unless you are smart enough to warn the user to turn Javascript on (and willing to lose business if the browser doesn’t have Javascript) I’d say handle the dependencies with separate pages. Better would be to have two versions, one for browsers with Javascript, and one for those without.
Some known rules and rules of thumb
Trust and loyalty are hard to gain, and easy to lose. Be careful when you have them. Take care in building them.
Link the logo to the homepage.
Anything from the branding up is going to be ignored. For example, if you put a link to the shopping cart at the top of a page, you had better put it somewhere else, too, because many people will never see it. (They’ve been trained by banner ads never to look at the top of web pages.)
Anything near animated ads (animated anything) will not be seen.
If you want a reader to read or concentrate, don’t have any animation visible.
Write scannable text.
Write good links.
Frames are bad. URLs are part of the user interface. Frames typically hide the content url from the user. You want people to bookmark and email urls.
URLs should be short enough to fit on one line of an email. If the URL is too long, some email clients will not recognize the second line, and your potential customer will see a “file not found” error, instead of your beautiful product information.
Search should be on every page. There could be a more advanced search page, too.
The top 350 or 400 pixels matter. People with small monitors need a sense of the opportunities of a page in those top pixels. Don’t waste pixels.
In a multi-stage process, indicate the current position. Also indicate the number of stages to the process.
Don’t demand too much personal information with registration – if you want people to register.
Remember that providing an incentive to register doesn’t mean people will ever come back to the site.
Narrowly targeted coupons are a way to create a pattern of use without overall price reductions.
Reduce the number of pages required. Each page can take a long time to display, especially secure pages.
Don’t demand registration before purchase. Nobody wants another dumb id and password. Just let us buy. Give us a code in case we need to reference the transaction again. You should have back-end software that can smartly connect various transactions to the same user (even when they don’t log in). If you don’t have that, don’t force the user to make up for your lack.
Bulletin boards need nurture to grow. Nothing is worse than a bulletin board with only four posts, the last of which was over a month ago. It’s better not to have bulletin boards than to do them badly.
Give users full price information as early as possible. Every product page should have a button: “total price” that calculates tax and shipping. If you do this, fewer people will “abandon” their shopping carts. And more people will use your site because they trust that you are on their side, not wasting their time. Users aren’t tricked into buying if the full price is hidden until late in the process. Instead, they leave and never return. This is a major trust issue.
The web is a conversation. If you really want to win, find ways to engage your customers. Ask for lots of feedback, and respond politely and efficiently to what you get.
The appropriate way to respond to a flame is with great politeness and appreciation. They cared enough to share their opinion, after all.
Indicate required fields on forms.
Copyright © 1998-2011 J. R. Boynton