Communication with Coders

In contrast to the wireframe being overly defined for the clients when discussing overall structure of the site in Project A, we found that compositional elements of pages were not defined in sufficient detail to communicate with the software development team responsible for implementation. The development teams' approach was to identify logical units within each page so that common software classes and routines could be identified early on. This entailed marking up the prototypes with regions regarded as logical units, and numbering them. Clearly this added another level of detail to the wireframe which we had not initially envisioned when designing it. Since the wireframe was developed in HTML using layers it was not technically possible to annotate the prototype itself, so paper copies of the pages were used and marked up. As development progressed, and the prototype was refined due to client requests and an improved understanding of the user requirements, it became increasingly difficult to maintain a link between the regions marked on the paper copies and the evolving prototype.

Given the lack of fidelity in the prototype required by the software coders, use cases were written to specify the user-system interaction in more detail. Use cases are a software development representation that describes the "dialogue" between a user and system in a task context. For example, in the task context of "Write an e-mail", the dialogue could be: (1) The user creates a new message; (2) The system displays an empty message window; (3) The user gets a recipient from the address book; (4) The system checks the validity of the address, and so on. These use cases were specified by use-case writers and then taken by a test team who developed test plans to better support the implementation effort. These additional specifications referred directly to particular parts of the wireframe — for example, the use cases detailed particular user-system interactions, while the test plans relied on both the wireframes and use cases. Maintaining the consistency between these multiple representations became more difficult as more and more people came to rely on the wireframe.

In terms of our dimensions, our prototype did not allow for sufficient detail in its description when the target audience was the software development team. Moreover, the unchanging paper copies became further out of synch with the evolving prototype as development progressed thus imposing an overhead on the communication between the HCI and development teams. Essentially the development team needed a view of the prototype that was at a greater level of detail than our own.

The same problem occurred again in Project B where the prototype was used as a means of communication between the HCI team and the software coders. As in Project A the prototype was not detailed enough to meet the needs of the coders. Therefore we adopted use cases to further detail the requirements on the functionality. Initially HCI was responsible for specifying the use cases. However, at a later stage the system developers took on this responsibility to make sure the use cases were detailed enough to support them in their work. The use cases together with the wire frame were used to drive the development process and to identify issues that needed to be resolved.

Defining Roles within the Project

Intranet project roles should be clearly defined at the outset of the project. This includes an understanding of job titles and of what each person adds to the project mix. It also includes an understanding of overlapping skills, and boundaries around their expectations of each other.

In Example A, two-thirds of the User-Centred Design group consisted of content writers and artists who were not familiar with the term UCD. The usability engineers were challenged to find their place within the group, to help clarify the difference between roles on the team, and to incorporate usability engineering techniques wherever possible.

To successfully integrate themselves with the rest of the team, the usability engineers worked to understand the value that each team member provided. Each person's role was considered equally valuable and respected, and each team member was encouraged to think outside of his or her role, even if his or her opinions were sometimes overruled. Focusing on the common goal helped promote a combined sense of ownership and teamwork that has extended throughout many different projects to this day. Still, the usability engineers should have gone one step further. Clarifying the role of each team member in writing would have formalized the plan, defining it clearly from the outset. For example:

1. Usability Engineer. Conducts field studies and other observations, creates conceptual models, researches best practices, conducts heuristic evaluations of early design models and concepts, content (text, links, etc.), and navigation, provides the team with design feedback throughout the project.

2. Visual Designer. Creates intranet graphics, selects colours, fonts, and other graphical elements (buttons, links, etc.).

3. Content Provider. Writes all of the text that appears on the site, including text blocks, link names, button names, and banners, if included.

It is less important that the information be well written than that it be clear. In Example A, the usability engineers found that true working definitions were more appropriate than those you might find in a textbook. If the members of the project team feel that there is overlap in roles, for example, writing these issues down is a good way to ensure that they are dealt with. Doing so at the start of a project helps establish working relationships, expectations, and limits. A "roles" document can also help the project leader to understand who is responsible for what tasks.

People's familiarity with these roles is another critical factor. In our Example B, none of the consulting company's project team had worked together before. Although the roles of Project Manager, Technical Manager, and Developer were well established within the consulting company, all of the people filling these roles were new employees. To make matters worse, the concepts of usability engineering and information architecture were new to the consulting company as well, so no one quite knew how to integrate them into the process. The lack of clarity regarding roles within the consulting company was amplified when external clients became involved.

After the usability engineer created several page layouts, the visual designer created three concepts for the client to review. One of these concepts deviated drastically from the layouts — the navigation was on the right side of the screen. Although the usability engineer had made it clear to the visual designer that the right side navigation was not usable, she was on vacation when the concepts were presented. The client loved the uniqueness of the right side navigation model and selected it as the framework for the site. If the visual designer trusted the usability engineer and clearly understood the implications of an unusuable design, he might never have recommended the unorthodox design to the customer.

In addition, the usability engineer should have provided the team with extensive data supporting her page layouts. The team could have referred to this when the usability engineer was out of town.

"Do We Really Need an Intranet?"

Many studies have drawn attention to the threats to usability that frequently emerge in the design and development phases of IT projects (e.g. Poltrock and Grudin, 1994). This case study goes further by illustrating how, despite the rhetoric, usability issues continue to be treated as a side-show in many IT projects. It demonstrates how the capacity of project team members to satisfy usability requirements may be compromised by the often intensely political nature of processes that are instrumental in getting projects approved.

The immediate tactical aim of the project was to demonstrate the possibilities for delivering interactive, multimedia-based training materials to staff directly through the bank's branch network. The longer term, strategic aim of the project was rather more ambitious, being nothing less than to convince the bank's Executive Board that there was a sound business case for investing in the creation of a single, integrated corporate intranet. This was to have an important influence on the subsequent course of the project.

BigBank is a large UK bank that prides itself in having a strong track record in technical innovation. As our case study opens, BigBank's Technology Division had just successfully completed a pilot intranet project. Almost immediately, moves were afoot among certain players within Technology Division and the Bank's Corporate Communications department to get BigBank's board to approve the development of a full-scale, corporate intranet. While the pilot project had provided a useful, practical example of the benefits that an intranet could provide, the champions of the corporate intranet project would have to make a separate business case for this new investment. Building a business case for a corporate intranet would not be easy, as one of the project champions explained: "Justification for intranet systems is usually a soft case and this has to be sold to hard-nosed bankers. The cost-benefits of the system are often long term and difficult to quantify."

What the project champions needed was an application that would justify the investment by demonstrating real financial benefits. Having found it, they could then put together a coalition of political support and technical expertise that could ensure the project's survival and eventual success. In the process, they would have to make compromises over the project's technical specifications and set limits on its scope in order to deliver a usable and useful application.

Early Problems: Whose Mental Model Is It, Anyway?

In the case of Rural Net problems arose early on with the development of the original interface to the web-site. This was based on user actions, with a button bar whose topic heading represented verbs rather than nouns.

Consequently, the interface was centred around a number of actions - enquire, submit, pay, notify and monitor. These actions could have a number of interpretations that were entirely subjective and dependent on the users' interpretation of the actions that they wished to perform. For instance: in the case of a user checking their local Council tax bill, would this be an enquiry, monitoring a payment, submitting a payment or paying? It assumed a particular mental model for users which was in practice impossible to predict. This problem was further exacerbated by the fact that none of the content providers were in a position to provide the specific functions promised by the action style topic headings.

The content providers were not happy with the original action-based interface. They anticipated that their end users would be put off by the use of language such as: "Citizen's View" and "Technical Annex". Structuring the site in this way also made the assumption that people would not visit Rural Net out of idle curiosity but with a clear goal of what they wished to achieve.

The original interface also included a personalization process, which gave the impression that new users must go through a registration procedure to access the site. Given that the site was sponsored by local government and the police, asking visitors for personal details could be seen as intrusive, although in fact, registration was optional and the intention was to help people viewing the site from public access terminals to save their favourite options.

The site also included a map style interface which gave access to geographical information in the region. This application had to be downloaded - a slow and tedious process which most users would give up on. The application itself was idiosyncratic and difficult to use.

Finally, there was no adequate help or site map and the search facility did not work. Given the obliqueness of the site's content headings this made Rural Net extremely difficult for the average user to navigate.

Expressing the Role of the User by Creating an Archetypal Character

Identifying an average user of the Internet, is at best implausible, and, more probably, impossible; but this does not exonerate systems designers from trying. The previous section described how a research method was devised to establish purpose, for the design of a novel IS, but mentioned at the outset how it is the wants or needs of the end-user that must always be the overriding purpose of any such system. Consequently, the method, although sufficient for ensuring compatibility between system and organization, was not enough to guarantee end-user satisfaction. As work began on prototype development, it became apparent that identification of end-users of the system needed further clarification.

Discussion revealed that the organization had very clear perspectives on some members of the public that take an interest in the heritage. They could be described as those that already made use of its services, its current customer base, and a very concrete understanding of their needs and wants already existed. Accordingly, there was a feeling that the customer, or potential user, was already known, and did not therefore need to be discovered, nor included in either development or system-testing. However,because the PastScape project was exploring an untapped area, its resulting application had the potential to reach a whole new customer base, customers whose identities were not yet discovered. Although internal belief and external reality may have been a perfect match, there was no evidence to assert this possibility, and without a concrete external user to target, the system risked only satisfying an internalized viewpoint, without necessarily improving the organization's dissemination of information. Furthermore, there is always a danger, with such an internalised viewpoint, that the wrong emphasis can be placed on decisions; for example, regarding which particular dataset should take advantage of a new, and potentially advantageous, system.

Many organizations are structured in such a way that different sections, divisions or departments have responsibility, and therefore ownership, for different elements of the organization's data. This carries with it the possibility that a dataset will be chosen according to some sort of purely internal motivation, rather than for the benefit of an intended user. In an attempt to resolve this issue satisfactorily, i.e. to promote wider internal acceptance of the principles of user-centred design, two different approaches were established. The first was to compose a "typical" user; the second was to explain the correlation between the potential new system and certain current business practices. These two approaches are outlined here:

The Intelligent 12-year-old

Because the perfect typical, or average, user does not, unfortunately, exist, early usability experiments for this project were conducted with the involvement of a variety of potential user-group representatives. The test- subject volunteer force (some 48 people, half of whom were males, and the other half, females) was composed of equal ratios of: heritage professionals; computer experts; lay people with no expertise in either heritage or computing; and, children aged between 9 and 11 years. However, in everyday discussions with EH staff it was impractical, to say the least, to try and explain that every element of the system was being designed to disseminate information to this convoluted cross section of society. Thus, all four types, and both genders, became assimilated into a single, easily explained, "intelligent 12-year-old". From the moment that this creation took life, explaining or rationalising any element of the system, to almost anyone, took on a new and surprising simplicity and clarity. Most people seemed to naturally understand what was meant by an intelligent 12-year-old, had no problem seeing why such a character had arisen from our collection of test subjects, and, perhaps most interestingly, accepted that such a persona was appropriate, as an "average" user of the Internet with a possible interest in heritage matters.

From Data to Information

The second approach taken, to demonstrate the importance of a target audience, was to clarify the functionality of a usable system by relating it to more easily recognised, non-IS, business functions. It was necessary, at various stages, to attain approval from people within EH who were well acquainted with dealing with the public, and whose natural responses revolved around familiar business processes, usually from a non-IT viewpoint, but often with an informed knowledge of web or IS principles. Drawing on the results of the initial analytical method, and through discussion with internal staff, a picture was revealed of some of the business practices that were already being used to disseminate database information to the public, and to other heritage professionals. The area of the organization's business structure that was most relevant to the project at that time, centred around EH's National Monuments Record Centre (NMRC) where members of the public could request heritage information. An enquiry would elicit a search by a team of in-house professionals, using various national databases and archives, and the results would be supplied to the enquirer. Essential to this process, which is of course an information system, are: the existence of data; an understanding of the data; an interpretion of the user's requirement; and delivery of appropriate information. Appropriate, of course, to the end-user. This, the process of turning data into information, is illustrated in Fig. 8.1. Within the NMRC, the in-house professionals perform this complex task by interpreting what the user wants, being able to understand the terminology and structure of the data, and then by presenting a suitable end-product.

Taking this already-understood process, or service to the use, and equating it to what a good IS should provide, was a useful ally in the explanation of the new interface, especially to those who were regular users of the Internet; many web-sites fail to provide this absolutely essential service, instead simply making raw data available. Such sites are not truly information systems, they are data storage systems with multiple-user access.

The Importance of Recognizing Underlying Perceptions

Every software developer, HCI designer or usability specialist is aware of the importance of making any system appropriate, or fit, for its intended purpose; and that the intended purpose of any system is ultimately that which the end-user wants or needs to do with it. On this basis, and before the PastScape project itself was born, a bespoke requirements-capture method was devised, incorporating several well-known analysis and survey techniques. The aim of this exercise was to try and identify useful and practical mappings between the business needs (problem domain), and the technological hardware, software and processes that were, or soon would be, available to the organization (solution domain). Although there was an expressed intention to develop a novel ICT application, and a desire to make use of VR and Internet technologies, at this early stage no specific thoughts were formulated about what shape any resulting project would take, nor to what end. Instead, the research method was designed to establish whether or not there were any business areas that could, at that time, benefit from the implementation of new ICT systems or approaches.

From the outset the pre-developmental research involved considerable consultation with a wide variety of staff, including senior personnel (directors), IS (Information Systems) staff, as well as specialists and users in other areas of the corporate structure. The input provided by such a variety of people, and their very different perspectives, inevitably proved to be extremely useful, and enabled a comprehensive and realistic overview of the organization to be established. The output included plans, descriptions, flow-diagrams and discussions of all of the organization's major functions; IT capabilities; divisions and departments; external partners; financial restraints; and its corporate and strategic visions for the future. The investigation was helped by the fact that, because this was effectively blue sky research, there were few negative pre-conceptions associated with it, and thus staff involvement in the early stages was fairly spontaneous and enthusiastic. The perceived potential, offered by the very latest innovations in technologies such as the web and VR, was great, and certainly worth a degree of investment in both time and effort.

There was also, however, a flip side to this particular coin. As a consequence of the fact that the project began with a clean sheet, and because the initial analysis focused on an examination of business functions, it was difficult to explain to those involved what it was that was being asked of them; interviewed staff, understandably, wanted an idea of what was to be developed so that they could temper their responses accordingly. Intuitively, they were trying to ensure that their input was itself "fit for purpose". This led to a degree of uncertainty that seemed to be counteracted by "playing safe", i.e. responses tended to be high-level, in accord, particularly, with the deliverables of an organization-wide IS strategy study that had been completed only a matter of months earlier. Whilst this may still have produced a fair overview of the IS elements of the organization, it meant that some "reading between the lines" was necessary to identify areas that could benefit from new technological systems, approaches or ideas; quite reasonably, no one wanted to consider the possibility of areas that "could do better", especially after so much time, money and effort had so recently been put into a substantial IS study. Furthermore, although the staff respondents were enthusiastic and helpful during the analysis process, finding someone to take firm internal ownership of the project, a "champion", proved to be a difficult task. Retrospectively this seems fairly predictable because, during the early stages, no one had the faintest idea what it was they would be championing!

Fortunately, belief in a positive outcome, combined with the continued help and goodwill of staff (including some with enough faith to take at least limited ownership), enabled the process to continue. Ultimately, the research method revealed a commitment to increase the dissemination of heritage information, stored predominantly in computer databases. It also revealed that, due to various constraints, this commitment was not being addressed as quickly as the organization wanted. Combining this factor with the earlier intentions to make use of VR and Internet technologies, it was decided to try to develop a system that would allow users to explore heritage data, via VR models, on the web. The only missing factor seemed to be who exactly these mysterious, obliging, "users" were!

Getting the Go Ahead: Cost, Timing and Glamour

The project champions found what they were looking for in the shape of a new, network-based training tool, the Network Training and Communications System (NTCS), with Corporate Communications as the project sponsor. In early lobbying for the project, its champions presented the following vision:

Corporate Communications plans to revolutionize the Bank's training and communication strategy through an exciting business vision known as the Network Training and Communications Service (NTCS). In branches, NTCS will be delivered via one or more (depending on the size of the branch) PCs. These PCs will be powerful multimedia machines that run a web browser and have a "network" connection (yet to be fully defined). NTCS will support intranet access and interactive training and will provide the hardware, software and network frame^work for running and managing of (CD-based) multimedia training and collecting trainee data via the web browser. All these facilities will be accessed and managed via the web browser on the PC.

While this pitch evidently attempted to capitalize on the glamour of multimedia and the World Wide Web (WWW), in the event, what made NTCS so attractive to the bank's IT strategists was its timeliness. The expected imminent arrival of the Euro would soon necessitate widespread training for bank staff, an extremely costly investment as the Bank must pay not only for the instructors, but also for venues, and foot the transport and accommodation bill for trainees. In addition, the bank loses the work of that employee for the period of the course. Corporate Communications argued that delivering training over a corporate intranet, using NTCS, would greatly minimise or, in some cases, even eliminate these costs. One of the project champions explained the business case somewhat more prosaically as follows:

The original benefits [of the earlier pilot intranet project] were the cost of printing the phone book, calls to switchboard, directory enquiries calls. With the combination of training, costs were saved regarding costs of transport and accommodation incurred sending people for training plus the time lost through them being away.

Identifying and Getting Access to Users

Successful intranet projects require access to users. In situations where this is discouraged, information may have to be gathered covertly. In situations where this is strictly forbidden, it is important to understand the limits and to find creative ways to work within them.

Identifying users of an intranet is as difficult as it is crucial. Getting access to them is more so. This proved to be a real challenge in Example A for several reasons. As is often the case, the project owners were concerned that employees would come to expect too much of the new portal. As a result, the usability engineers were told not to show associates prototypes or concepts that might "get their hopes up." Attempts at gathering information through field studies were repeatedly denied. The usability engineers were not to create any expectations at all, but to generate excitement whenever possible.

What to do? The project leaders repeatedly described themselves and the developers as typical users, suggesting that the team observe them instead of going out to the stores. The usability engineers accepted the offer and treated the observations as sales opportunities. In one example, the usability engineers observed a project leader retrieving information from the newly designed intranet site. After conducting the observation, the usability engineers described the type of information that could be provided by actual (rather than representative) users, and how a fresh set of eyes might be useful. Eventually, the project leaders referred the usability engineers to customers who could be relied on to provide less biased feedback.

We took every possible opportunity to educate the business and technology sides of the project on the types of information that we could gather through field studies. One of the most difficult concepts for us to land was that users could provide us with useful information about their use of the intranet even if they had never used it. For example, users could have let us observe their current work areas, showing us their offices, allowing us to understand what systems they used and how an intranet site could make their lives easier. These educational opportunities challenged our ability to remain positive and resilient At times we spent more time complaining about our limited role than working to make the best of it. We should have visited the retail environment and gathered the information we needed any way we could.

In Example B, the usability engineer had access to the current site's webmaster and the supervisor of the employees who were most likely to use the site. Both of these people were invaluable resources. Although the client's Project Manager had forbidden the usability engineer from asking these experts what the site would be used for, the usability engineer was able to gather this information by asking good, carefully framed questions about the underlying technology. The usability engineer initially asked what type of files were being accessed on the site and then followed up with a questions about how the users would use the files and what the users^tneeds were for the files. The subject matter experts didn't share the project managers' ideas that all the analysis was already complete and were therefore willing to discuss the users' need with the usability engineer. This data, covertly gathered and analysed, was used to build a solid information architecture, which was critical to the success of the site.

Project Management Means Managing Conflicts of Interest

Many of the project's problems occurred through the bureaucratic way in which it had been set up. European union funding procedures and the plans required to get and maintain EU funding are based around supporting a large bureaucracy rather than supporting effective project management. Rural Net was not unique in this, new technology projects do not fit well with old style management procedures.

EU guidelines set specific targets for outputs, but the project lacked any coherent project management plan or practical imperatives on the usability and design of the site. A good example of this was usability testing: the EU plan specified that this should be carried out (by a local university), however it was scheduled in near the end of the project, when there would be very little scope or commitment to change the existing web-site. There was no understanding that usability activities need to be co-ordinated with development activities in order to achieve product improvement. Similarly, day-to-day project management was not well coordinated. The overall effect was that the project was heavy on bureaucracy but low on efficiency.

Effective, supportive and professional project management is a vital component in the success of any well run software project. When that project incorporates elements of user centred design and usability, project management skills become even more vital.

Web-site development projects require a particular blend of project management skills to enable usability considerations to be accommodated. The project manager must have an understanding of the scope and importance of usability work and know the right points at which to apply usability consultancy. Most importantly they must have the "soft" interpersonal skills to convince the client of the need for the usability element of the project, and to persuade the development team to implement in keeping with the usability consultant's recommendations. But the project manager must also be sufficiently technical in order to bolster persuasion with consistent technical reasoning when the development team present obstacles or objections of a technical nature.

Designing web-sites to suit diverse international markets and cultures is now accepted as good business practice. It illustrates that the organization responsible for the site is sensitive to local needs. Unfortunately for Rural Net, the original idea in the EU proposal was to produce a pan European site with a standard template which would be used by all similar projects running in four different countries. The UK content providers wanted something that was tailored specifically to the requirements of their users. In the end this was achieved but it did cause delays in the project work.

Structuring Information: Content Labels which Speak the Users' Language

The project partners met at a special interest group where they could discuss progress and contribute their ideas for the Rural Net site. Many of the partners were new to the web and did not have a strong idea of what they could expect from the technology; they had even less experience of what their end users would find acceptable. This scenario is fairly common in the current development of commercial web-sites, and unless checked can open the way to some serious usability problems.

It is important that information on a web-site is structured appropriately and in a way that a wide range of users will understand. Oblique content labels and cul de sacs are still a big problem with many web-sites: search and use of content labels are the two main ways in which users navigate a web- site (Rosenfeld and Morville, 1998). Users' (especially naive users') browsing and searching strategies are still very much based on the analogy of printed media.

An unambiguous information architecture is the key to the usability of a Web-site. Information architecture is a topic which is much discussed in industry at the moment but in many cases it is not practised effectively. This could be due to the fact that good information architects are hard to find. The qualities required include a good technical understanding of the structuring of information plus an ability to see things from the users' perspective. (Many usability consultants fulfil a dual role including that of information architect.)

Testing and Roll Out: "Keep It Simple" Wins the Day

The decision to use BigBankTV required that TVs and PCs be located within the branches in mutually accessible places, and this was eventually to prove a considerable stumbling block. The original placement of the TVs within the Branches had been chosen to allow the whole of the staff to view BigBankTV broadcasts, whereas meeting the needs of an interactive training system required a more isolated setting. The Bank's Property department established that moving the TV with fittings and connections to a location that was compatible with both purposes would be very costly, and even physically impossible in some branches. So, late in the day, the NTCS team returned to the aim of incorporating the TV image within the PC. A number of ways of achieving this were identified:

• TV tuner card to feed the signal into the PC for display on the screen.
• A system for delivering images via networks using new technology that was unproven, but was backed by BT.
• A second system for delivering images via networks using technology that was proven, but from a supplier unknown in the UK.

In the event, both the network-based suggestions were rejected because, in their different ways, they were judged to be too risky at this late stage in the project lifecycle. This left the first option of using the TV tuner card, which was not as forward looking as the other options, but was proven and did not require direct integration with the system.

The project survived this final alarm, and was eventually successfully rolled out into the branches. However, it is clear that this outcome owed little to a systematic, principled and early consideration of usability issues and rather more to the project team's capacity to salvage something from a crisis. Though this particular project was considered a success, we argue that coping with usability threats as they arise is, in general, a risky strategy for usability staff to pursue. Instead, they need to become more politically aware and seek out organizational positions that will enable them to foreground usability issues from the very beginning.

The Beginning of Progress: Common Sense and Consistency

The catalyst for change occurred when the project missed some deadlines which put its funding in jeopardy. At this stage one of the industrial sponsors, Telco, assigned a small team to work on Rural Net and helped to pull it around. This team provided project management and development skills. Their work involved liasing with all the project partners and making some common sense improvements to a site prototype.

The Telco team (especially the project manager) understood that people expect Web conventions to be fairly standard and become resentful and confused when this is not the case. So actions (verbs) on the original button bar were replaced with categories (nouns) — education, tourism, business, community, transport, training.This meant that users could search for information using hypertext links in a way that was familiar to them from its use in other web-sites. More importantly for naïve users it provides an analogy that is similar to the categorisation used in printed material, such as magazines, books and newspapers.

This version of the interface made great improvements to the navigation of site, providing a use of language which was more in tune with prospective users. It illustrated that usable web-sites can be created by following some very basic rules. For example: making sure that users can access all the functions of the site all of the time. The layout of horizontal content topics button bar (underneath the header) and vertical functions button bar (to the left side of the screen) ensured that users could navigate their way around the site without needing to scroll and that the options available to them were always visible. These comments may seem obvious, but the briefest of excursions on to the web will show that too few designers show consistency in their use of navigational constructs. They do not consider the needs people have for visual metaphors, for example, the web page as an electronic version of the magazine or catalogue.