Once a site has been developed (or partially developed), you can test it to ensure that it is usable and spot any potential problems.
Testing has to be done by other people, not the designer (who is too experienced with a site to realise its problems). A good way to test is to make up imaginary "use cases" corresponding to the different groups of user identified. A tester can then pretend to be one of those users, and see how easy it is to achieve their goal.
Obviously, formal use-testing is normally only possible on a commercial site. However all sites do benefit from some testing - ideally, you should always have other people test your site before it goes live.
Testing is necessary
However well a site was designed, there are bound to be a few problems - inefficient design decisions which can make the site annoying or incomprehensible to some users.
It's difficult or impossible to spot many of these problems yourself, as a site designer. Because you know the site intimately and understand exactly how it works, you'll have difficulty putting yourself into the place of somebody who's new to it. So it's necessary to have other people help you test the site.
One way to test a site is to work out some imaginary users of the different types you identified earlier. You can assign each tester one of these users, complete with a task they have to accomplish, and watch them to see if they have trouble accomplishing it.
Testers
Because it's more difficult to spot problems in a site you've developed, you will need to find some uninvolved people to test it.
Unless you are working on a corporate site, it might seem difficult to find testers, but in fact you can probably badger friends or family members into helping.
Use cases
Sometimes it's helpful to structure your testing, rather than simply asking people to find problems with the site. One way to achieve this is to come up with use cases.
A use case is a description of a task somebody might want to complete using the Web site. You can come up with use cases for imaginary users in each of the different types of people you identified for the site's audience. For example, if you run a recipe site, and one group of people is inexperienced cooks, a possible use case might be one of these inexperienced cooks looking for a bread recipe. You can make these use cases as detailed as you like - perhaps even making up a name for the imaginary user.
Note: The term "use case" is not standard within the field of usability: it comes from software design, which is my own background.
Roleplaying
Although you could consider the use cases yourself when evaluating the site's navigation etc., if they are being used for testing you will need to assign each of your testers with a use case.
The tester then "pretends" to be the person described in that use case, as far as possible, and attempts to achieve that person's goal.
Ideally you would use testers who are as close as possible to the imaginary people in the use cases. (For example, if the use case says that this user knows nothing about cooking, then ideally you would choose somebody who knows nothing about cooking to imitate that user.) Of course, this isn't always possible.
Learning from testing
You can learn from this testing by watching the tester as they try to find their way through the site. (Obviously, you should not help them out or offer suggestions!)
Here are some examples of what you might observe and learn:
- Do they pick the correct navigation options first time? If not, the choices may not be sufficiently clear.
- Do they need to spend a long time considering navigation choices? If so, there may be too many options.
- Do they need to go through many screens to reach their destination? If so, you may need to provide additional navigation or useful shortcuts.
- If the information they want is not actually available on the site, do they discover this quickly?
- Does it take them longer than necessary to read text, or do they have to struggle to read it?
