There are three essential criteria for an effective web site:
1. The web site must serve a purpose for its owner.
2. Users need to be able to perform their tasks without problems.
3. To remain effective, the site must be maintained and updated.
It seems very simple, doesn't it? Yet many web sites (most websites, perhaps) are not fully effective, because they fail to meet some of the above criteria. Let's consider each one in more detail.
A website exists to serve a purpose for its owner, and during the early years of the Web the most common purpose was to experiment: to try out this new technology, find out what was possible, get some experience with it - and not be left behind by competitors.
All but the latecomers have now moved beyond the experimental stage, and websites are now expected to serve a range of purposes, generally marketing-related. Some of the common purposes are:
Most sites have several sections, designed to attract different audiences and fill different needs. If those audiences and purposes are very different, it may be better to have two separate sites, with different domain names. Nike (for example) do that: they had nike.com for their customers and nikebiz.com for their investors (though in 2004 they seem to have combined the two). Perhaps this saves each of the two groups from being upset by seeing the home page intended for the others. With this dual-site strategy, customers can be told how low the prices are, while investors are told how high they are!
We suggest that you make a plan for each section of your site, listing the type of audience it is intended for, and the outcomes expected from that audience. You also need to compare the outcomes with the inputs: if an e-commerce site costs a ton of money to set up, and results in a tiny number of sales, you need to reconsider.
This leads to the next part of one of Audience Dialogue's favourite planning methods: known as the "five hows and five whys" or alternatively "means-end chains" or "laddering". Basically this involves asking a sequence of questions beginning with "why" until the answer is so fundamental you can go no further - like "to survive" or "just because!" Here's a page explaining five hows and five whys in more detail.
The Program Logic Model is related to the ladder of Whys and Hows. It was originally designed in Canada, in the 1970s, as a way of helping in the evaluation of complex government programs, but it works just as well for smaller projects. ("Program logic" in this sense is completely unrelated to computer programs.)
Program Logic uses a similar model to the ladder of Whys and Hows, but in this case you work up the ladder asking How instead of Why. We already know why you move up the ladder, but how can it actually be done? With our variant of the Program Logic Model, you describe a scenario of how your goal could be achieved. Let's take the example mentioned earlier: an organization (let's say it's a software producer) putting copies of its product manuals on its website to reduce the load on its call centre. Here's an example of a program logic model for this:
1. Customer has problem with the software.
2. Customer looks for the manual, but can't find it.
3. Customer looks elsewhere for manual, and eventually visits producer's website.
4. Customer finds manual on website.
5. Customer uses manual, and solves the problem - no need to contact call centre.
Each step follows logically from the previous one - but at the same time each step may result in various outcomes (maybe for some customers, step 2 is "give up"), and may itself be the result of other causes (maybe some people who are thinking of buying the software look up the manual on the website). Therefore the above 5-step sequence is only one of many possibilities. A common way to produce a logic model is to make a diagram, with multiple inputs and outputs for each step. (Here's a more detailed page on program logic modelling.)
Having produced a diagram (or maybe sticking to the simple one-ladder model), you then try to estimate how many times each of the actions occurs. For example, how many customers are expected to follow the 6-step sequence above? You won't be able to get an exact answer, but showing the arrows on the diagram with various appropriate thicknesses should clearly show the expected paths leading to website use.
When a program logic model has been built, the next step is to test it against reality. What really happens - and how often? The logic model is a great aid in evaluation, because instead of trying to directly connect the central point of the ladder ("having a website") with the top ("a better life for the website's owner") you can evaluate each stage separately. If the bottom doesn't in fact connect with the top, you can find out where the path was lost, by using the Program Logic model.
Usually, what you find is that reality is much more complex and messy than the idealized diagrams first produced. The customer problem above is a highly simplified example, with a single chain of 5 steps. Most real models are much more complex, with branching, and multiple paths to and from each step. When made into a diagram, they look more like a cobweb than a chain.
Using the five hows and five whys, and program logic modelling, you now have some tools to sort out the purpose of your website. When that's done, the next step is to make sure it's usable.
A web site is easily usable when...
However, usability applies only to a website: it doesn't include other aspects of effectiveness, such as being able to find the website on a search engine, or the contribution of the website to the performance of the owner organization.
Usability can be assessed in two ways:
(1) with real users, at real computers, trying to solve real problems. This is highly informative for website owners, but, because it involves primary research, is not cheap.
(2) "Heuristic assessment" - which means checking a web page against a set of principles drawn from usability studies. This is much cheaper and quicker, and there's software to help. On the web, try Watchfire (formerly PC Bobby) and usability.gov on accessibility. However, the software doesn't pick up many types of problem. Though heuristic evaluation can discover a lot of faults, a real usability test will discover a lot more.
It's not much use to set up a web site, then ignore it. It will probably get out of date quickly - which will not send a good message to your customers. But it's not only the web site that needs to keep up to date: so do your contacts with your customers.
And to get the maximum benefit from your web site, you need to have it feed customers back to you. The easiest way to do this is through email, so one of the most important parts of the web site is your email address.
But receiving email is not enough: you also need to answer it - and Internet users generally expect a prompt response. After all, they're used to computers, which react almost instantly. You should have the capability to respond to every email within 24 hours - or if you can't do that, instantly reply with a message along the lines of "We're overwhelmed at the moment, but we'll get back to you as soon we can."
When you set out the three criteria for successful websites, it all seems obvious (setting aside the complexities of the Program Logic model). But the amazing thing is that so many web sites don't meet the above criteria - and some of the biggest companies are among the worst offenders - so the number of multi-million dollar bankruptcies among dot.com companies in the last few years is hardly surprising. Conversely, some of the most effective web sites we've seen are fairly small, low-budget ones: obscure products filling niche markets, and expanding their sales from a small area to worldwide. For example, a local shop selling confectionery online is reported to recovered its website development costs within two months.
So what do you want your web site to achieve? It's easy to say "All the above" - but you need to actually plan a series of steps which will achieve each of the above goals. And then, to make sure you haven't wasted your money and time, you need to set up a way of measuring how effectively the site reaches each of its goals.
So the steps involved are:
1. Deciding on the purpose of the site
2. Designing the site
3. Evaluating the design
4. Creating the site
5. Telling the world about the site
6. Evaluating the site's effectiveness with real users
7. Using the evaluation to improve the site.
Though many web design companies do only steps 2 and 4, Audience Dialogue's new approach is to go through all of these steps. The Ladder of Hows and Whys and the Program Logic Model are useful at several stages, while usability testing (and related methods) are most helpful at stages 3 and 6. We've found that the key to successful websites is to have a system where you can learn from your mistakes, and quickly correct them.
Doesn't that sound simple and obvious? Surprisingly, many organizations have trouble managing this process - for three main reasons:
If your organization has fallen into one of those three holes, it will need to find a way of climbing out. These are management problems, not technical ones, so they can be difficult to fix.