In 2000 I gave a talk on Web Sites that Suck to the Cambridge Web Developers. Here’s the text of the talk. it gives a good overview of what to do and what not to do from a functional perspective.
It’s worth noting that this talk was made a long time ago. Most of the sites have changed. The user experience of the web has grown too, so some of the ideas in here are no longer as valid as they were. Also I have not rebuilt the links since moving Tangled Time……
On the shoulders of giants
Let me start by saying that there are people who are far more experienced in web and user interface (UI) design, and much of what is below comes from them. Have a look at the work of Jakob Nielsen, Vincent Flanders, Bruce Tognazzini, Joel on Software, and Philip Greenspun for work on web design, and software interface design. Some of the examples used come from these sites.
Hopefully the sites used as examples will have changed themselves by the time you read this. (Written in November 2000.)
Exposing my biases
I don’t have a design background. I have a developer background. That means that I prefer functionality over art when a web page is meant to fulfil a task. I do consider attractiveness and balance in a visual design as functional; they contribute to the utility of the page. I think that design should contribute to functionality and not override it.
Just as black as the kettle
I fully accept that the design of version 0.2 of Tangled Time leaves much to be desired. I have lots of wasted space. I am not altogether a fan of the colour scheme I’ve chosen. Fonts a bit mixed. And more. In time I will fix these things. If you have criticism I am willing to hear it.
That’s over with, away we go then ….
Smack in the face
The user interface is how a user thinks of your web site or program. It’s the thing they see and interact with. This means that it is probably the most important thing to naïve customers, followed closely by functionality. This may seem obvious to you (but trust me, not all developers understand it). People do judge books by their covers. If a new user sees a bad interface, it is as likely as not that they will just go somewhere else. It does not matter at all how wonderful the underlying functionality is if the user isn’t able to manipulate the web page or program sufficiently to do what they want to do.
So that’s the point of designing your user interface. To increase views, user satisfaction, happiness. To do this you must help people meet their goals. What are their goals? Not to feel stupid, not to make mistakes, have fun (at least not to be bored), not to be slowed down, to find stuff out, to find other people, to get a great big raise∦
The lesson to take from this is that you should design for your audience. An audience of beginners has different needs from an audience of advanced users. If you are designing for advanced users, then you may be able to expect them to guess how the interface for your web site works (perhaps you have flyover popups on subtly distinguishable words in the text of the page). A new user is not going to get the subtlety – your web page will be wasted on them.
Designing for your audience is hard thing to do, because as a web designer you almost certainly fall into the category of advanced user. You want to experiment, to do new and exciting work. Curb your tendencies when you are working on functional sites. Design for your audience NOT YOURSELF.
The one true way is that there isn’t one true way
What’s the best way to lay out your furniture in your lounge/living-room? If you think for a little while you’ll see that most often there isn’t a single arrangement that is best, but there are things that will make the room much nicer to use, and others that will make the room somewhere you avoid. There are lots of dumb things you can do which will make your room unusable. Don’t put your TV on its side, even if it looks better that way. Do choose furniture that suits the room – probably it’s not a great place to mount a urinal. The form should follow function.
Web pages are the same. There is no one best way of designing pages, but there are lots of things not to do. Art sites should be arty and experimental. Functional sites should try hard to make things smooth. So UI design is mostly about what not to do. (Hence the examples in the following are of what not to do. Don’t assume that the examples below only illustrate the error being discussed at the time – most of them have multiple problems.)
User interface ideas and rules
The following list is not in any particularly good order – it’s roughly ordered from the big ideas to the smaller ones. But remember that little things can make very big differences.
Test your design
You are not perfect. (Hmm – pot, kettle, black.) You will make mistakes. The very, very best technique for improving designs is to test them. Do this informally. Ask up to six people what they think.
Even better – ask them to use the design – ask them to perform one or two tasks. Sit behind them and keep your mouth shut as they do it. (Keep your mouth shut. Don’t say a word. Not a thing. Do not give any help. Whatsoever. No help. Don’t point, murmur, move the mouse, click, or offer any indication of what to do. Do not speak.)
I think I’ve been pretty clear on that point. But just in case – do not offer any help.
This is a hard thing to do.
Your instinct is to help. To explain. But you mustn’t. If you do then you won’t learn a thing. Remember that you won’t be there to explain to all the other users of your work.
So don’t help at all. Instead, write down the problem that they are having. Afterwards analyse why it’s happening. There is something about your design that was misleading. That’s what you need to fix.
Example: Try this site. Go into the shop – can you figure out how to put a vacuum cleaner in your basket? Make your window a little smaller. Can you get back to the front page? If you can get to the pages about the DC06, can you navigate back to the front page?
Design for your group of users
Again, this is worth reiterating several times. Think about who your users are. What are their attributes? Now design for them.
New computer users often have problems with mouse control – they need big block elements. They may not know about scrolling down a page – put important stuff at the top. Advanced users can deal with lots of info closely packed as long as it is well delineated in blocks. Users with disabilities need appropriate interfaces – ones that can be read by voice software perhaps. Or ones with very high contrast and large type. Build deep sites with short pages for inexperienced users. You can make shallower sites with longer pages for advanced users.
Follow the Design Language
There is an evolving Design Language for web pages. Don’t break it. Do change your sites as the Language evolves.
A Design Language is a standard way of doing things – all cars have steering wheels and dashboards. There were cars that steered using other mechanisms, but people standardised on steering wheels. Designers can change the texture of the steering wheel and the layout of the dash, but users expect both these things. If you try to sell a car that is steered using reins you will have wasted a great deal of venture capital before you go out of business. (Sounds familiar anyone?)
When you break the Design Language people will go elsewhere.
As applied to web design this means that you should follow standards. The element that is top left – usually a logo – should link to your home page. People understand that navigation bars or tabs appear at the top of the page, or the top left. Put them there. Unless you are doing an experimental site use the navigation bar as the site navigation mechanism, do not invent another navigation mechanism for a functional site. It will confuse your users. (Hint: look at this site first in Internet Explorer. Then, after exploring the navigation look at the site in Netscape.)
You should lay out all your pages to the same standard, so that users don’t have to hunt around to navigate.
Example: What happens when you click on the picture at the top-left of this page? Does the page leave you feeling secure about using their service? (Note: keep an eye on the download time too.)
Keep the important stuff near the top, in the middle
Put the most important thing in this position. Make sure it is important to the user, not to you. Try to avoid any design that looks like a banner ad. Users are beginning to ignore banner ad areas. They just don’t see them.
Put titbits on the side of the page. It seems like the right hand side of the page is becoming the default place for this sort of information.
Example: Who do the owners of this site think is most important to users of the site? (Note: since initially finding the site it has been much improved.)
Research a few years ago showed that a horrifyingly large percentage of users didn’t scroll down pages. I suspect that this behaviour is a novice-behaviour, and that this is changing. Nonetheless, put the important stuff first. Make it a hook.
If you want people to click they’ve got to know that they can
Children learn very quickly that buttons are for pressing, that door-handles go down, levers can be pulled. Affordance is the idea that widgets should look and behave properly so that people can transfer their day-to-day knowledge of the real-world to computers. If you want a user to click something to perform an action, it should look clickable. Buttons encourage pressing. Tabs encourage investigation.
This means that flat buttons are a bad idea. Buttons that only reveal that they are buttons on mouse-over are a very bad idea. Breaking the behaviour of established UI elements is a bad idea – tabbed sheets should behave like tabbed sheets. They shouldn’t behave as links. (Explore this site. Click on just about any link – then use the tabs – finally click on the Home tab.)
Your interface is the crust on a pie (or interface and metaphor)
Think very carefully before designing an interface around a metaphor. If you design your site to be like a house then you are bound by the conventions of houses. Breaking the convention leads to confusion. You can’t lead someone from the garden to the second-floor bedroom, without people wondering where the front door went.
Especially – do not design a website after the metaphor of a book or a catalogue. It’s been done. It didn’t work.
Metaphor is sometimes appropriate. But be careful lest you fall through the crust and land in the stew. (Yes, imperfect metaphors lead to mixed and confusing metaphors).
Visual design is good at conveying large amounts of information
I cannot add anything to the definitive works on the subject. Read the books on this by Edward R. Tufte. The Visual Display of Quantitative Information, Envisioning Information, Visual Explanations . (For the UK readers: The Visual Display of Quantitative Information, Envisioning Information, Visual Explanations) These are the best books written in the area – superbly bound and presented. Read them in the order above.
For people who only need an intro to the ideas there is Visual & Statistical Thinking (or in the UK) which is a paperback containing parts of Chapter 2 of the Visual Display of Quantitative Information.
Avoid implementation models in the user interface
That’s a mouthful. It means that when you have a database back-ended website you should start by thinking of how users want to use your site and design an interface that does this, then tie into your database, rather than starting from your database model and trying to put that on a web page. Your user interface should direct people to do the right thing – it should match the mental model that a user has, not the internal structure of your backend. (Of course the ideal is that your backend matches the user’s mental model, but this doesn’t often happen.)
Again, this may seem obvious, but in practice, unless you think about it it can be quite a difficult problem. The easiest thing to do is to expose the database directly, but in fact the database structure is likely to be a generalised structure which does not apply in all cases.
Example: Look here – if it’s so easy, why do they need to explain, and if they do need to explain then why aren’t they doing it on the page that needs explanation. Now click on a pair of glasses from the pictures on the left. These are glasses for children – very, very few children are going to need much more than basic lenses. There may be a child who needs bifocals, but should this be a decision that everyone has to make? This is a case of exposing your implementation model.
Smooth the path for the user – don’t block them
Remember that your user is not captive, they can leave at any stage. Every time you put a barrier in place, some users will leave. Therefore, put as few barriers as possible in place to their progress.
Of course this depends on the current and future value of the user; you may not mind driving away poor people if you are a site that only sells exclusive luxury goods – perhaps you could do this by requiring the user to enter a credit card number so that you can check their credit level. This would be guaranteed to remove most people without the required limit. Of course it would also remove many people who could meet the test, but were not prepared to enter their credit card details. And it would remove users who may have future value.
Barriers come in many guises – forms that require the user to enter too much information, forms that only return data entry errors one at a time, requiring users to log-in before they are able to access whatever interests them, a difficult navigation system, barriers to finding information.
Forms should have the minimum possible number of fields. If there really honestly and truly are reasons for you to requiring anything more than an email address then if it is possible for the user to not completely fill out a form, or to enter badly formed data, you should tell the user about all the problems at once, and not one at a time.
Philip Greenspun has a good idea – he suggests that you should not collect information on people in large chunks. You should slowly build up a profile of the user, requesting additional bits of information one at a time, as the user becomes drawn into using a site.
Don’t make colour the only clue
About 8% of men are colour-blind in one form or another. About 0.5% of women are colour blind. Design your web-pages with this in mind. Test your pages. The very best source of information that I know of about this is here and if you have full colour sight, Robert Hess, the author, gives you specific, easy to use techniques for testing what colour-blind users will see.
Navigation: Categories and user goals
Near the beginning of this list was the injunction to think about the goals of the user. You should categorise your site according to the goals. Links should reflect the goals – for instance ‘Technical information about about our Widgis’, should lead you to finding out about the dishwasher by attributes, rather than by model number, since most people are going to know that they want a high-performance luxury, extra-large Widgi, and not a Widgi XC232-L-U.
Navigation part two
Navigating inside an unknown information space (a map, a web page, a database, a mall) is difficult. Users need to know Where am I? Where have I been? Where can I go?
It is very useful to have a sense of your location in relation to other parts of the space. On a web site this means that your pages need links to ‘nearby’ relevant pages. Perhaps these may be the parent, children, and sibling pages in a hierarchy, or other relevant pages when you are at a page as a result of a search.
If you have a large site it’s a good idea to leave a trail of breadcrumbs indicating where in the hierarchy the user has been. Yahoo does this very well. When move through their pages you have a trail at the top of the page (Home > Computers and Internet > Data Formats >) which tells you the location of the page.
Because users are quite likely to have come to your site through a search engine they will not have seen any entrance pages. Make sure that your users can navigate around your site no matter where they are in your site. Make certain they can always get to the home page. (By clicking the top left icon.)
The navigation system can sometimes perform the same task as a menuing system – it gives novice users lessons in how to use the system. It’s likely that advanced users will have bookmarks or shortcuts into the system.
Hide and seek
Despite your best efforts some users will not be able to find what they want if your site is larger than 20 pages (and other’s won’t be prepared to spend the time). You need to provide a search facility. It should be accessible from every page. Put it near the top of the page – on the left or right hand side.
Don’t mess with the link scheme
Users understand that links are underlined. Don’t change this in the interest of good graphic design. (Yes, it’s looks better if links only show on mouse-over, but it has less utility – people have to guess where the links are.)
Users understand that links that they have visited are a different colour from ones that they have not yet visited. Browsers and other sites have trained them. Make sure that they are different.
Observe cultural conventions
Easier said than done. Here are some easy rules – try to spell in the language of the audience. (I’ve used colour in this text – I should use color – pot, kettle, black. Oops – just used a proverb that I’m not sure that all the readers will understand.)
If you want the audience to click on something, don’t make it red. Red is a warning colour. Naive users won’t click. It’ll confuse them. Don’t put anything unimportant in red type. It has to be very important to be red, with immediate impact on the user. Error messages should be red.
Duh – download size
How long does it take to download the page? Sites with many graphics look terrific. But that’s of no use if no-one is prepared to wait for the page to display. So, if you use pictures, make them simple and small. Clip the colours by hand to compress them, or invest in one of the excellent tools on the market.
But it’s not just pictures that are a problem. If you use tables extensively, some users with older browsers will not see the page until the entire table has loaded.
If you insist on using plugins, you’d better make sure that something is happening while the data is flowing to the plugin. Flash animation are notorious for having a long download time and no option to skip the page. Which takes us to…
See this? See what?
Unless there are truly compelling reasons to use plugins – don’t. Before you use a plugin you need to be sure that all your users have the plugin, otherwise you’ll immediately knock out a percentage of the users. Sure you can point to the download, but someone has to really want to see your stuff to go get the plugin, install it, and likely as not, reboot.
Don’t use anything leading-edge if you need a functional site. It won’t work for many people, your time and effort will be wasted. (I still don’t use frames unless I can’t avoid them.)
In that vein, it’s not a good idea to use browser-specific dynamic html. Sure it looks great, and what do the rest of the world see? A blank page? A badly messed up page?
Which leads to the obvious…
Make the text readable. Don’t put text on backgrounds that make it hard to read. (And remember colour-blind users.) Use good design sense – don’t clutter (Example). Make things clean.
Test on other browsers, early and frequently
Pretty obvious. Each browser has its quirks. Look at the design of your site on browsers other than your default one. At the time of writing (November 2000, I think it safe to design for level 4.0 and later browsers.) You can download old Netscape browsers from here. Look for Internet Explorer on those cover CD’s (but watch out about installing it on your main machine).
But did these people do it? Try their site in Netscape 4.7 or earlier.
Study current designs
Learn from the past. Don’t make scrolling text or marquees. No cursor trails. Constantly running animation are not trendy. They make your site look old.
Realise that the design of sites is still evolving. I’ve said that the Design Language includes an icon at the top left, with home attached to it. In a few years time the language will have evolved further. The user population will be ready for the next stage, and sites that currently break the rules may have defined the rule. On the other hand – the number of experiments is likely to greatly outweigh the number of successful language patterns. Those that don’t follow the accepted patterns will wither and die, so for functional sites it’s probably best to follow, rather than lead.
Wow!
Finally, here are some sites that work functionally. They don’t break the rules, and manage to make themselves attractive and usable.
HMV loads quickly and has a pretty high information density. I’m not a fan of the colour scheme, but that’s a personal choice – it looks good if you have colour-blindness.
Marks and Spencer has lots of graphics. They are very carefully optimised for downloading, but still look good. They have a clear navigation structure. (Note: updated since I first looked, and I think that they have regressed a little.)
Slashdot is a daily distraction site for software developers. It’s designed for advanced users and contains a lot of information.
Please feel free to point out the sites that you think are good and bad. Try to give solid reasons for your judgement. Let us know what you think contributes to good web design.
Jeff Veit – Tanasity
http://www.tanasity.com/ – Tanasity develops software and net applications
http://www.chase.org.uk/ – Cambridge Hi-Tech Association of Small Enterprises – brilliant networking for hi-tech companies around Cambridge, UK
Tanasity
Tel: +44 (0)1223 721499