Pattern 13: User-centred site structure *
AKA: TASK-CENTRED SITE STRUCTURE

Back to Diagram 1 - Getting started Back to Diagram 2 - Useability Back to Diagram 3 - Adding detail Back to Diagram 4 - Workflow/security

View sensitizing image - NHS Direct
Predict what concerns your users might have

You are constructing a SITE MAP (12) and trying to decide how best to organize it. Pretty much the only thing you’ve got to go on is what you found out using ESTABLISH THE USE CASES (3) and CLASSIFY YOUR SITE (11).

Sites concerned with modelling, problem exploration, and so on are best built around key business objects BUT... some workflows have to be enforced.

Therefore

Build the site structure around the use cases, especially if it is a workflow site. Establish the user’s domain ontology and build the site around the business objects, especially if it is a problem exploration site. Adopt the philosophy of expressive systems.

You will need to ensure that CONTENT IS LINKED TO NAVIGATION (76).

Contributors and sources
Richard Dué, Detlef Vollmann


Discussion - forces - known uses

The NHS site shown above appears to be organized around what its designers think are frequently asked questions. The dominant use case here is a request for information on a medical topic of real or imagined concern to a member of the public.
Navigation schemes should correspond to the way people think about the domain not the way the vendor sees it. As an example, consider a user, like the present author, who decided some year ago to learn to play the Irish tenor banjo and needed tutorial material, music and possibly a teacher who lived locally. Searching the web using Netscape produced the following result.

View image - Netscape search results


Nothing local, nothing about musical instruments, nothing about sheet music, nothing about tuition! What a way to run a portal. Other search engines and more refined searches led to sites concerned with the manufacture and sale of banjos. The point here is that the designers of sites and portals make assumptions about the user’s intentions. This is all very well if the guesses are accurate. However, it is usually better to try to understand use cases for a wide range of users.

Nielsen (2000) reports that, at one site, usability tests showed that users succeeded in their tasks only 9% of the time when they used navigation organized according to the mental model of the site’s owners. Using a navigation scheme based on the users' tasks as they perceived them gave a success rate of 80%. Such a 9:1 difference could easily be the difference between a commercial site’s continued existence.

One way to get help with the problem of how to explore the problem structure and the users’ views of it is to focus on the use cases. The goals or post-conditions of the use cases need a vocabulary that supplies the ‘domain ontology’; i.e. the type model of the domain. Graham (2001) discusses this from a non-usability point of view but Pawson’s (2002) work on Expressive Systems provides a particularly useful interpretation and useful guidelines.

Browse the language What is Wu? Look at an example pattern sequence Structure of the patterns
Comment on Wu Contributors Return to TriReme home page Links to related sites