Beta Phi Mu - Chi Chapter, Student Award for Scholarship
1997/1998 Nominee

List of Annual Award Winners

Web Design and HCI: Problems and Promises

Patrick J. Dawson
School of Library and Information Science, Indiana University

In this paper, I will examine the relationship between the activity of designing information sites for the World Wide Web and the field of Human Computer Interactions. From the perspective of HCI, web site design offers some interesting problems that ar e not present in the creation of traditional, stand-alone software products. Because of the recency of the WWW's rise to prominence, HCI is only now beginning to address these new issues. A challenge for the field, therefore, will be to rigorously exami ne the process of web site design and offer recommendations and guidelines, as it has with the areas of software and hypermedia publishing. That such counsel is needed by web site designers becomes readily apparent when looking at the multitude of badly conceived and poorly designed sites now populating the web. [ 1 ] As Borges and his collaborators point out, "[t]he proliferation of pages with poor usability suggests that most of the designers of WWW pages have little knowledge of user interface design and usability engineering. This is a s erious problem that needs to be addressed..." (Borges et al., 1996: 1). There are, in fact, any great number of guidelines currently published on the WWW offering advice on how to design effective and pleasing sites. Unfortunately, very few of these ar e grounded in the theories or empirical data that have been developed in HCI. In fact, as Morris notes, "[a]t this point, HCI as a discipline has had a relatively limited impact upon the development of the web" (Morris, 1996: 1). It is my contention, however, that it is precisely the field of HCI that has the most to offer web site designers. Therefore, part of this paper will be devoted to examining different areas within the HCI literature that might be of most use to the indiv iduals who are creating and maintaining web sites.

This paper is divided into two main parts. In the first section, I will identify some of the new and unique issues that designing for the medium of the web present to the field of HCI. In the second section, I will discuss areas of the HCI literature th at are particularly useful to web designers and propose a method for web site design that is based upon these materials.

The question can be raised as to how similar the activity of designing World Wide Web sites is to the design of more "traditional" software and hypermedia products. The very fact that I am presenting a paper that attempts to relate web design to the esta blished HCI literature suggests that I believe there are important similarities between designing for the web and designing other types of software. Yet there are obviously some important differences as well -- differences that the field of HCI is only b eginning to consider. The most obvious dissimilarities involve the levels of technical knowledge necessary for design, and the types of entities that carry out the design process. While the creation of traditional "stand-alone" software applications req uires extensive technical expertise, and is the largely the province of specialized companies, designing web sites requires relatively little technical knowledge, and can easily be done by almost anyone. But such surface distinctions, while important to note, are not what primarily concerns me. Rather, I am more interested in how the medium of the World Wide Web presents a set of challenges and issues to designers that are different to those presented to creators of traditional software products. Alth ough there are undoubtedly some similarities in the process of creating web sites and stand-alone software, there are also some significant variations that result from the distinct characteristics of the mediums they are intended for. Put simply, the WW W is a very different environment from a single computer system or limited network, and designing applications to be displayed on it presents the designer with a number of unique issues that they must consider.

Perhaps the most fundamental aspect of the web medium that designers must come to terms with is that it is platform independent, which means that materials on the web can be accessed by a wide variety of computer systems and browser software. Beca use the WWW is system and browser independent, and because the different systems/browsers have varying capabilities and features, the designer of a web site does not know and cannot control: 1) how their pages will be visibly rendered for any particular user (e.g., a pleasing and coherent layout on one system/browser may look terrible and be confusing on another), nor 2) what functionality of the site will be supported by the configurations of different users (e.g., important layout features like tables may not work in all browsers). Thus, designers of web sites have to account for the fact that they will have only a limited amount of control over the interface that their site will present to a visitor. As Simon Shum notes, "[t]here has never been a h ypertext system that was so large that no-one could be sure what hardware or software the end users might be using. The user interface design community has had to get to grips with the concept of designing with this uncertainty (Shum, 1997: 5). Creator s of sites who want their work to be accessible and usable to a wide audience either have to design it in a way that will allow all major systems/browsers to view it effectively (designing for the "lowest common denominator"), or they have to consider pro viding different versions of the same site that are optimized for different types of users (Shneiderman, 1997: 4). While the former option may be unacceptable for designers who want to incorporate the latest technological advances into their sites, and the latter option requires extra work on the part of designers (who would have to present multiple versions of the same site), these are really the only options for dealing with the uncertainty caused by the independent nature of the WWW.

A second unique feature that has to be considered by designers is that web pages represent "third-level interfaces" for a user. Above the level of the individual web page, a user is also interacting with browser software and an operating system, each whi ch provide their own interfaces to the user. The most important levels to focus on, for my purposes, are those of the browser and of the individual web sites/pages. A web site, as it is experienced by a visitor, really has a dual-interface: one that is provided by their browser software, and the other which is provided by the site designer. Both the browser and the site levels are important, in that each provide mechanisms that determine how a user will interact with the site and how they will navigate the site. Browsers, for their part, display the individual web pages, and provide at least a minimal set of navigation options for the user. Different browsers, however, vary in their capabilities for visually rendering pages and supporting oth er features -- ranging from the text-only capabilities of the Lynx browser to more advanced software packages like the latest versions of Netscape Navigator and Microsoft Explorer, which support a wide variety of media types (text, images, video, audio) a nd features (Java, Javascript, tables, etc.). Browsers also vary in the navigation mechanisms that they offer to users. While all browsers support basic backtracking and jumping movements, the more advanced browsers also incorporate features identified in hypertext literature as aiding navigation -- features like history lists, bookmarking, and footprinting (Smith et al., 1997: 17; Andrews, 1996: 1). At the level of the individual web site, user navigation is affected by the access mechanisms that are presented (e.g., site overview maps, tables of contents, navigation bars, etc.), as well as the hypertext links embedded within the pages. Because the "dual-interface" will affect user's interaction with and navigation through a web site, and because th e platform-independent nature of the WWW means that site designers cannot know which types of systems and browsers will access their sites, the creators of these sites have only limited control over the user interface that will be presented to a visitor. Site designers need to carefully consider a number of issues, therefore, regarding the functionality and navigation facilities which their site provides, and how these will relate to and be affected by a variety of browser platforms.

A third unique issue that confronts designers of web sites relates to the question of access speed. Because assess to a web sites comes via a connection to the global Internet, and is therefore affected by bandwidth constraints and network traffic , users of the WWW will likely experience some (greater or lessor) delay in the system's response to their actions. This can cause a number of problems. Slow connections, whatever their cause, not only serve to frustrate a user -- and increase the cha nce that they will abandon a site if it is responding too slowly -- but it also delays feedback to the user as well. Because connections to web sites are typically asynchronous, the system will respond to a user only after she takes some action (Nielsen, 1995a: 190). And if there is too great a delay between action and reaction, confusion, anxiety, or frustration may result. Discussing hypermedia systems, Jakob Nielsen notes that."...the response time for the display of the destination node is critical for the user's feeling of navigating an information space freely" (Nielsen, 1995a: 209). And if the connection to a particular site is slow, users may feel that they are not fully in control. While the need for adequate speed is largely taken for grant ed in most software application development, and in usability research on these products, it is an important issue that faces web users and designers alike (Smith et al., 1997: 11). Although some of the factors that affect access time, such as user's co nnection speed and network traffic levels, are beyond the control of web designers, there are obviously some steps that site creators can take to minimize the potential difficulties. In general, web pages that are smaller and less graphically-intensive will load faster than those which are larger and more graphically rich. Web designers, therefore, can insure that their sites will be accessed as quickly as possible by keeping the file size of their pages fairly low. But such a solution may not always be considered optimal for designers, who might want to capitalize upon the multimedia capabilities that the WWW offers. Thus, trade-offs are inevitable, and there is no single best solution for any case. Such trade-offs between access speed and presenta tion are much less important of an issue for developers of other software products, and as Shum notes, "[w]eb designers must therefore prioritise different criteria to ones they might use in designing a smaller scale hypertext or multimedia CD-ROM, in ord er to balance interactivity with acceptable speed of access" (Shum, 1997: 4).

The issues of platform independence, dual user interfaces, and access time all pose challenges to web authors, who must carefully consider the issues raised by these factors when deciding how to best design their sites. Unfortunately, they are also face d with the additional problem of having a much more limited set of interface tools to work with. Compared to the range of potential tools and techniques available to authors of stand-alone software applications, the web designer has a relatively p rimitive set of resources to work with. According to Richard Miller, "HTML's limited set of objects and interaction styles is a step backwards for interface design compared to the growth of interactive computing over the last 30 years" (Miller, no date: 1). Not only do web designers have fewer interface widgets as their disposal, but nature of the web medium also makes it difficult or impossible to tightly couple relationships between interface elements (Rees, 1996: 4), or to utilize some navigation ai ds identified as beneficial in hypermedia research (such as multiple windowing, user annotation, zooming, etc.). Thus, web site designers are faced not only with a lack of control over their interfaces that their sites present, but they also have fewer r esources to draw upon to maximize the potential of these interfaces.

The final special issue regarding web site design to be discussed is how the dynamic nature of web sites affects their creation. Whereas the first four issues that have been examined all present problems to the web designer, the dynamism inherent in the WWW may actually prove advantageous for these authors. In the case of traditional software development, the design cycle is fairly well bounded, and when the product is released to the public, there is little or nothing that can be done to change it. This places a great burden on the development team, who much ensure that the product meets all of its predefined requirements and is relatively bug-free before it can be released. If problems arise afterwards, they can only be remedied through costl y and time-consuming methods, and significant changes to the product may have to wait until the next version is developed. Web sites, however, are much easier to change after they have been "released" to the public. While this does not mean that site c reators can afford to be lax in their initial design efforts, it does mean that if problems with the site become apparent after it has been mounted, they are relatively easy to change. This means that the iterative design cycle for web sites can be much less bounded, and may continue after the site is implemented in order modify problem areas. In fact, because of the dynamic nature of the web medium, it is probable that a site will undergo constant revision and change. While this offers site designers a greater degree of flexibility, some care needs to be taken to make sure that the site is not changed so often or so much as to create confusion among repeat visitors.

The five issues that were discussed above all relate to differences that exist between designing web sites and traditional software applications. Although these issues may present special conditions that web site designers must consider, the discussion w as not intended to imply that designing for the web is a more difficult process than creating other forms of software. In fact, by almost any measure, web authoring is a much simpler task than creating stand-alone software products. The above discussion was merely intended to highlight the fact that the process of creating web sites is in some ways unique, and that designers in this medium are faced with different types of considerations than those faced by individuals in the software industry. To be s ure, there are also some common considerations that creators in both field face, such as how to structure the design process, how to construct a meaningful navigation system for a hyperspace, and how to create a usable interface. This discussion of the d ifferences between web authoring and traditional software publishing, therefore, should not suggest that the existing areas of the HCI literature which are oriented toward "traditional" software issues are not useful to web designers. In fact, there are many areas within the HCI field that have a great deal to offer web designers. And with the growing importance of the WWW, more attention within the HCI community has been directed at this new medium. Too many individuals who are currently producing web sites seem to feel that this activity is somehow sui generis, and has little to learn from the body of accumulated knowledge about such issues as design methodology, hypermedia development, and interface design. While I agree that the web medium is in s ome ways unique, I would reject any contention that designing for the web is so different as to render existing work in the field of HCI irrelevant to it. In fact, it is apparent to me that individuals who produce web sites should be more familiar with what the field of HCI has to offer. The question can be raised, then, as to what areas of HCI are most relevant to web designers. The following section of this paper will address this issue.

A blanket statement such as "the HCI literature is important for web designers" is not very useful because the field itself is so broad and varied. Although arguments could be made for including many different strands of HCI into a discussion of relevant areas for web design, I will discuss only four areas that I think are particularly significant: the literatures on software design methodology, hypermedia, user interface design, and usability. Before moving on to discuss these areas, I feel that a f ew caveats are in order. First, given the context of the assignment and the fact that I am addressing several different segments of HCI, my review of the literature in these areas will be fairly selective. I make no pretensions of having thoroughly surv eyed these four areas. Also, I have attempted to the degree that is possible include fairly recent works that are explicitly oriented toward issues involving the WWW. Finally, I have included a few relevant works that are outside of the HCI field, stri ctly defined. My discussion of the literature will not be formally segmented into different sections. Instead, I will examine various relevant threads in the course of proposing a method for designing web sites that is based upon my interpretation of th ese literatures.

Although I have spend a considerable amount of time identifying some ways that web design differs from other types of software development, the general processes involved in this activity can be similar to those employed by authors of traditional software . Levi and Conrad argue that building web sites "can and should be viewed as a major software development effort.... The life cycle of web creation is identical to that of traditional software: requirements gathering, analysis, design, implementation, testing, and deployment" (Levi and Conrad, 1996: 1). Although they do not identify it specifically by name, it seems apparent that the general type of methodology that they see being suited for web design is the User Centered Design (UCD) approach. I wo uld concur that a design effort for the web would be well suited by employing a UCD perspective, but would argue that it should be specifically tailored to take into account specific types of tasks required for authoring a hypermedia application. While t he general UCD approach is fairly generic, therefore lending itself to a wide range of projects and design sequences, I believe that it is also flexible enough to be applied different types of design efforts. Before suggesting such specifications for a UCD approach to be used in the context of web development, however, I'll identify the basic aspects of the user-centered design process that I feel make it particularly valuable for web site creators. Then I will examine in greater detail the specific st ages of the web design approach that I believe is most valuable, drawing on the different areas of the HCI literature that were identified above for support.

The main strength of the UCD approach, in my opinion, is that it represents a set of general principles that underlie the process of design rather than any specific sequence of tasks to be carried out. These general principles include an early and contin uous focus upon users and their requirements, an iterative approach that intersperses design efforts and user testing throughout various stages of the development cycle, and an that emphasis upon operational criteria for usability assessments. While su ch a philosophical underpinning can lend itself to different types of design-phase sequences, the UCD approach is often used with the fairly standard software design process of requirements analysis, design, implementation, testing, and maintenance. In general, this type of process can be useful to employ in the task of designing web sites. Some modifications should be made in a few areas, however, to recognize the specific challenges involved in creating a hypermedia information product, to emphasize the value of user testing throughout the design process, and to recognize that web design is often carried out in different contexts and by different types of individuals than is the case with traditional software products.

The earliest stages of designing a web site should involve a modified type of requirements analysis suggested by the basic software design model. As the general principles of the UCD approach suggest, much of the emphasis here should be devoted to ident ifying the prospective audience for the site and specifying what their needs may be. Given the distributed nature of the WWW, and the fact that the audience for a particular site can conceivably be very broad, it is likely that this task can be carried o ut only at the level of generalities. But as Shneiderman points out, even when broad user communities are anticipated, there are usually underlying assumptions about who the primary audiences may be, and it is helpful to make these assumptions explicit ( Shneiderman, 1997: 6). After identifying potential users, it is also helpful to assess what kinds of tasks they will likely want or need to perform when visiting a web site. How this is to be done is a matter of some controversy. In the development of many traditional software products, a formal task analysis is carried out, and some authors writing about web site design, such as Rice et al., seem to favor such an approach. (Rice et al., 1996: 1-3) Other works on software development, however, believ e that task analysis can be carried out in a more informal manner, utilizing methods such as user observation (Nielsen, 1994: 18) or imagined scenarios (Apple Computer, Inc., 1992: 42). I believe that a formalized approach to task analysis is unlikely to be widely practical or appealing to the web design community. As Dillon and McKnight note, "...the fact that hypermedia-based interfaces are frequently being used in novel applications renders it very difficult to perform formal task analysis, specific ally in the context of usage, or elicit user requirements to any degree of precision" (Dillon and McKnight, 1995: 120). While Dillon and McKnight were not discussing the WWW specifically, the extremely distributed nature of the web's user population sho uld only amplify their sentiments. Beyond the fact that the potentially broad nature of web site audiences makes it hard of impossible to conduct formal task analysis upon users, the level of specialized knowledge required for utilizing this method is li kely to be absent in many real-world cases of web design. Thus, more informal methods to identify user requirements may be a more realistic alternative.

While the identification of potential users and their tasks should be an important element of the early stage of web site development, care must be taken to also consider the goals and requirements of the site's stakeholders as well. (Boiling, 1995: 2) T aken in tandem with the information gained through an analysis of users and their tasks, the articulation of the site owner's purposes should help designers identify the basic information content to be included in the site and the types of features that w ill need to be incorporated into the design. Such preparatory work is important to provide a firm foundation for the subsequent design phases in the site's development.

The actual stage of design for a web site should be carried out in line with the general principles of the UCD approach. In other words, the process should be an iterative one that involves developing and testing prototypes at various stages, and the res ults of these tests should be fed back into the design efforts. But the generalized model of software development identified above, which portrays design as a sort of undifferentiated stage, is not very helpful here, as it provides little guidance about what types of tasks need to be carried out to effectively design a web site's architecture and interface. It is in this respect that the Object-Oriented Hypermedia Design Method (OOHDM) proposed by Schwabe et al. seems to be particularly useful to consid er. (Schwabe et al., 1996) Although I do not agree with all of the aspects of this model, I do think it provides some useful guidelines that can be incorporated into a web design effort.

Schwabe and his collaborators contend that designing a web site is tantamount to designing a hypermedia application, and believe that their OOHDM model is directly applicable to this process (Schwabe et al., 1996: 1). Their model is partially compatible with a UCD approach, in that the different stages of the design process are "performed in a mix of incremental, iterative, and prototype-based development styles"(2). The central core of their methodology, however, is based upon formal modeling, and the y eschew the type of user testing that I believe is important to include in web site development. Nonetheless, the fact that this model is based explicitly upon the specific requirements of hypermedia development, and the general structure of the design process that they set out makes this method important to consider. For my purposes, the most valuable and interesting aspect of OOHDM is that it breaks the design process into separate "activities," each of which focuses on a different aspect of an appli cation's architecture or interface: concept design, navigational design, and abstract interface design (which are followed by implementation) (2). This general structure, and the specific types of concerns and "products" that they identify as the foci of their different "activities," are very useful to a web design process, and can, I believe, be incorporated within a generalized user-centered approach. But the specific modeling techniques which they employ are probably less practical in the context of the web design community, which seems to be largely comprised of individuals who are not HCI experts. Therefore, I would propose to keep the "outer shell" of the OOHDM model and incorporate it within a user-centered design approach, while jettisoning the methodological core of formal modeling. It should be recognized, therefore, that the discussion of the various phases of the design process that follows represent my own adaptation of the basic OOHDM structure within a user-centered approach.

The first activity suggested by the OOHDM model is conceptual design. In this stage of design, the basic topography of the web site will begin to be specified. The earlier work carried out in the requirements analysis stage should have identified the basic information content of the web site. The primary task at this stage is to organize this content into meaningful and understandable categories. General issues that need to be addresses in this phase are what types of information should be grou ped together and how to organize these groupings within some coherent categorization scheme. More specific issues may involve decisions on page length (whether to divide related content into fewer but longer pages, or more shorter pages) and labels to be applied to the categories that have been identified. The product of these efforts will be the identification and specification of the information nodes that will constitute the core of the web site.

Even in this early stage of design, it is a good idea to conduct user tests, for as Miller notes, "...the earlier one starts [testing], the larger the payoffs in time savings and user satisfaction" (Miller, no date: 7). It is quite possible that the desi gners may have grouped information and created categories in ways that do not make sense to potential users, and their assumptions should therefore be tested. The terminology adopted by designers also needs to be examined, because as researchers like Gra y have found, users often understand categories and words to have meanings other than the ones the author intended them to have (Gray, 1990 -- as cited by Smith et al., 1997: 7). One method that can be used as a test of conceptual clarity and terminology is card sorting. According to Nielsen, "card sorting is a common usability technique that is often used to discover user's mental models of an information space" (Nielsen, 1996:2; also see Levi and Conrad, 1996: 2)) In designing the internal web site f or Sun Microsystems, Nielsen has used this method with a small number of individuals to examine how they think information should be grouped together and what labels they feel should be applied to the groupings (Nielsen, as cited by Horgan, 1996: 2). If users have rather different ideas from the designers about how information should be organized within the site (or how items should be labeled), the designers should reconsider their initial categorizations and redesign as they feel necessary. [ 2 ]

While the concept design phase begins to provide the site with some organization, by virtue of preparing the information nodes that will be offered, the second stage of structural and navigational design shapes the way that these nodes will be rela ted to each other and identifies the means by which the site's structure will be made apparent and accessible to visitors. There are two primary types of tasks that should be carried out in this stage. First, the designers need to establish the basic st ructure and relationships of the information categories identified in the concept design phase, and determine how the various nodes will be connected. Decisions have to be made about what type of organizational structure will be imposed upon the site, wh ether it be linear, hierarchical, or some other form. Such decisions may be influenced by the predetermined purposes of the site and the expected types of tasks that prospective users will perform, as different kinds of structures lend themselves better to different tasks (Smith et al., 1997: 5). [ 3 ] Identifying the basic structure of the site will also allow designers to plan the relationships of categories at both the global level (relations between different levels of categories ) and the local level (relations between nodes within similar levels), and connect them accordingly.

After the primary structural framework of the site has been specified, the designers then need to decide how the topography of the information space will be made apparent and accessible to visitors. According to Bevirt, once site creators have developed a model of the information in a site, they should begin to prepare navigation tools that will clarify it's organization (Bevirt, 1996: 2). [ 4 ] This is a critical task, because as research has shown, users of hypertext systems can o ften suffer from the problems of disorientation and large cognitive overhead (Conklin, 1987 -- as cited by Balasubramanian, no date: chapter 4, p. 1). Since users may have trouble understanding the structure of the hyper-space they are in, and since elec tronic text often suffers from a problem of homogeneity (Nielsen, 1990: 299), designers need to take care to make the organization of their site explicit to visitors, and to provide mechanisms that will allow users to understand their present location and successfully navigate throughout the site. These issues can be addressed by determining what types of access structures and navigation tools will be provided to visitors. As was mentioned earlier, all web browsers provide at least minimal navigation su pport (backtracking and jumping), and some of the more popular versions also provide more advanced options as well (history lists, bookmarking) (Smith et al, 1997: 17) While these mechanisms can be of use to a visitor, the site designer can not count on any particular range of features (except for the most basic ones offered in all browsers) being available or understandable to the individuals who are viewing their site. Designers must focus on what they can control, and therefore must develop a suite o f access structures and navigation aids that are clear and accessible to all visitors, independent of the particular software they are using to access the site. Consulting the HCI literature, particularly in the areas of hypertext development, can offer some guidance to site creators on what types of mechanisms can be adopted. Thuring et al., for example, argue that designers can help increase the coherence of a site for the user and convey the structure of a hyperspace by providing a graphical overvi ew (Thuring et al., 1995: 59). Such a mechanism is widely cited in the literature as being of value. But because not all users will be able (or choose) to view graphics, other types of access mechanisms should also be provided. Hoffman suggests that de signers employ an array of navigation devices, including detailed, text-based tables of contents and topical indexes (Hoffman, 1996). Overviews, tables of contents, and indices can help a visitor develop a sense of the site's organization and structure, and provide means for them to navigate to desired locations. Designers should also consider how to develop more localized navigation tools to be used on individual pages as well. Providing users with well designed navigation bars on pages can help them maintain a sense of location and context, while also providing them with an important means to move freely throughout the information space. In order to be useful to visitors, however, such tools need to be created so that they are predictable and consis tent in the ways that they can be used and the results that they produce (Bevirt, 1996: 2).

As was the case with the first stage of the design process, the structural and navigational design phase should be accompanied by user testing. Basic questions that should be addressed in the testing are whether potential users understand the overall structure of the site, whether they can find information in the site, and whether they can effectively navigate between different sections of the site. The tests might be conducted in a free, exploratory fashion, in which users are allowed to determine their own course of action, and designers look for areas of user confusion, slow-down, or mistakes (Lev i and Conrad, 1996: 2). Or the users can be given specific scenarios and tasks to accomplish, with designers gauging how well they performed (Levi and Conrad, 1996: 5). In either case, designers will probably want to ask that users to "think aloud" whil e they work so that their thoughts are made explicit. Because the site's interface has not yet been developed, the tests will likely have to be conducted through the use of paper prototypes. The use of such "lo-fi" prototypes is widely accepted as being a valid technique for usability testing, and as Nielsen points out, "[f]or some projects, user reactions to prototypes with few or even no working features can give you significant insight into the usability of your design" (Nielsen, 1995b: 88). When usi ng paper prototypes, however, testers must take care to "...explain the limitations and missing features to users. Once this is clear, you can learn a lot from user interaction with what is there -- and learn what their expectations are for what's not" ( Nielsen, 1995b: 88). If users experience significant problems with the design that is presented to them in these prototypes, the creators of the site need to make necessary adjustments and test their revisions accordingly.

The final stage of the design process is interface design. While the earlier phases of the site's development have specified it's content, organization, and structure, the site still does not have a "face" to present to a visitor. Developing the "look and feel" of the site takes place in this stage. There are actually a number of different types of tasks that have to be performed here: interface elements (including things like icons, buttons, graphics, etc.) have to be created and selected, bas ic features of the site (forms, search engines, applets, etc.) have to be incorporated, and all of these things -- along with the basic information content -- need to be combined in detailed page lay outs. It is likely that the stage will be carried out in an iterative fashion, in which successively more detailed and specified interfaces are developed, instead of trying to produce a "final" interface all at once. As Nielsen notes, "[c]urrent practice in usability engineering is to refine user interfaces iteratively since one cannot design them exact right the first time around" (Nielsen, 1995a: 303)

There is a great deal of HCI literature on interface design that the site's creators could consult with as they work on this stage. While I have pointed out earlier that web designers have a less robust set of interface tools to work with than do authors of traditional software products, the basic principles for screen design identified in the existing literature are generally applicable for web sites (Rice et al., 1996: 6). And there is a growing body of work that offers specific guidance for web autho rs on issues of interface design and style as well (Sun Microsystems, no date; Apple Computer, Inc., 1995-96; Borges et al., 1995; Kahn, 1995; Rees, 1996; Rice et al., 1996). Although the specific recommendations may vary in these different works, there seems to be a general agreement on some issues, such as the importance of consistency in layout and behavior of interface objects, offering good affordances for these (especially in the case of image maps), and employing some sort of standardized layouts for the levels of a site. Web site designers would be well suited by examining some of these works when they are creating their site's interface for guidance.

While the published interface guidelines can be of great use to web site designers, I do not believe that carefully consulting them reduces the necessity of subjecting the resulting interface designs to user testing. Borges et al., however, take a contr adictory position. They argue that design methods that are based upon user testing may not be practical, and are too time consuming. A more suitable alternative, they believe, is to provide designers with a simple set of guidelines for designing pages t hat are developed from expert heuristic evaluations (Borges et al., 1995: 1-2). Although I agree that guidelines are useful to consider, I also believe, along with Levi and Conrad, that "...up-front usability guidelines do not by themselves guarantee a u sable end product", and that "...a distinct validation process is required" (Levi and Conrad, 1996: 1). As to the issue that user testing may be impractical, it is true that some extra time and effort may be required on the part of the designers, but I b elieve that the payoffs from effective testing are to great to be passed over. And as Levi and Conrad note, "[e]xtremely useful usability testing can be performed reasonably easily, reasonably quickly, and for almost no cost other than staff time" (Levi and Conrad, 1996: 2). The types of testing that I have been recommending are in line with the "discount usability engineering" methods suggested by Nielsen, which are intended to be fairly simple and inexpensive. Getting user feedback throughout the des ign process is, I believe, very important if the site is to be easy and pleasant to use.

If the interface is developed in an iterative fashion, as was suggested may be the case, user testing can be employed throughout this stage to assess the usability of each version. Testing in this stage will involve having users interact with working "mi d-fi" or "hi-fi" models of the site, as the situation warrants (Nielsen, 1995b). Some of the same questions examined in the previous stage of testing -- can users locate information or perform required tasks, can they effectively navigate around the site -- may be revisited again to make sure that the interface elements are not a hindrance to the subjects. And because the specific features of the site have now been incorporated, these should be subject to testing as well. The form of the tests will pro bably be user walk-throughs, which examine how well they perform some predetermined tasks. During the test, the "think aloud" protocol should be employed. At this stage, the designers may also want to consider devising a post-test questionnaire to measu re users subjective feelings, and to solicit their suggestions. As always, the results of the test should be considered carefully, and if problems are identified, they should be dealt with.

After the interface has been tested and finalized, the basic design process for the site is over. All that remains to be done is to actually implement the site and make it public. As I noted in the first section of this paper, web sites are fairly easy to change once they are mounted, and it is likely that a process of refinement and modification will continue. If unforeseen problems develop, the custodian of the site can make the appropriate changes.

In this paper, I have examined the activity of designing World Wide Web sites and how this relates to the field of Human Computer Interaction. Although I discussed at some length the ways in which the medium of the web presents unique challenges to desig ners -- challenges not yet adequately addressed in the HCI literature -- I have also attempted to demonstrate that the process of developing web sites can be grounded within the existing body of work in this field. In doing so, I have proposed a method for creating web sites that builds upon the several strands from within the HCI literature. (A short summary of this design method is included as an Appendix) Whether or not this particular model is useful to the people who are ac tually designing web sites, it is important that these individuals become more aware of what the field of HCI has to offer them. For the vast potential of this exciting new medium is being threatened by the proliferation of confusing and unusable sites. Simon Buckingham Shum feels that "...the Web, as the fastest growing interactive system in the world, offers a golden opportunity for HCI to make a difference" (Shum, 1996: 8). And as the web becomes increasingly important as a means of communication, i nformation sharing, and commerce, I believe that HCI will begin to have a larger impact upon the web design community. The stakes will be to high for this field to be ignored.


Appendix -- Overview of the Proposed Web Site Design Method

General Principles: Stages of the Design Process:
  1. Requirements Analysis
  2. Design -- Seperated into three phases:
    1. Conceptual Design
      • Work on categorization and organization of information content (how to group information together, what content goes in which category). Develop labels for categories.
      • User tests -- Does the categorization make sense to users, do the labels you choose suggest what information the categories contain? (ex. -- Card-sorting exercises to test organizing principles, category labels)
    2. Structural and Navigational Design
      • Establish basic structure and relationship of information categories (flat structure, hierarchical structure, linear structure, etc.) and determine how the categories will be connected
      • Determine what navigational aids/access mechanisms will be employed (common navigation tool, site map, table of contents, index, etc.)
      • User tests -- Can users find information in the site, can they navigate between sections without difficulty? (ex. -- Test users with a paper prototype or with a simple mock-up of the site; may want to employ "thinking aloud" protocol with this)
    3. Interface Design
      • Create/choose interface and navigational elements (icons, buttons, navigation tools, graphics, etc.)
      • Work on adding in the features of the site (forms, search engines, applets, etc.)
      • Combine these with content to create page layouts (work on "look and feel" of site)
      • User tests -- Can users locate information or perform required tasks, can they successfully navigate around the site, do they understand how to utilize the features... (ex. -- Test users with working model of the site. Employ "thinking aloud" proto cols. May want to administer post-test questionarre --what did they like / dislike)
  3. Implementation of Site

Endnotes

  1. I should make an initial clarification here about how I am the term "web site" throughout the paper. I am really referring to sites that make a seroius attempt to provide some type of information resource via the web, whoever they a re produced by, and whatever the type of information they involve. I am not referring to personal collections of web pages which are intended more for amusement or entertainment purposes. I know this is a fairly fuzzy distinction, but I want to convey s omehow that my analysis is directed primarily towards more professional web sites. [ Return to text ]
  2. Nielsen recognizes that such fairly simple tests carried out on a limited number of subject can not provide definitive evidence on usability questions, and that designers must user their own best judgement when interpreting the resul ts. (Nielsen, 1996: 3) [ Return to text ]
  3. Smith and his collaborators recognize that because web sites may have many different users with different types of tasks, no single information structure will likely be optimal [Smith et al., 1997: 6]. But considerations of the pri mary target audiances and their needs, even if these are not definitive, should nonetheless be taken into account when making a decision as to which structure to impose upon the site. [ Return to text ]
  4. Bevert is not talking about formal modeling here. Instead, he is recommending that designer produce a "simplified but revealing model of the information in the web site." (Bevirt, 1996: 2) [ Return to text ]


Bibliography