Competitive Analysis: Understanding the Market Context

by:   |  Posted on
“While user-centered design focuses on user needs/tasks, and information architecture focuses on content, these two aspects alone offer an incomplete picture.”

Effective web design, from the simplest brochure website to the most complex web application, needs to involve an understanding of context. While user-centered design focuses on user needs/tasks, and information architecture focuses on content, these two aspects alone offer an incomplete picture. What is missing is the context: the environment in which the website or web application is used as well as the market in which it exists.

Rosenfeld and Morville’s “Three Circles of Information Architecture”: diagram offers a visual representation of these overlapping areas, although I propose a slightly different view:

Relationship of context to content and users

Exploring one aspect of this context, the business marketplace of competing companies/products/services, is the focus of this article. Our primary tool in this exploration is competitive analysis, which is an examination of the websites/web applications of your competitors.

The role and benefits of competitive analysis

Competitive analysis, as the name implies, is an exploration of the companies in a given industry sector or market niche that are competing with your company’s products or services for market share. The analysis may be an in-depth exploration of the top five competitors, or a larger number of competitors could be examined (typically with less depth in the analysis). In most cases, the client will have identified the target competitors for you.

While this article focuses on competitive analysis in the for-profit arena, it is worth noting that non-profit organizations can benefit equally from this analysis (which they might term a comparative analysis, if they viewed the other organizations as working toward a common goal with them).

Understand the competition
The primary benefits of any competitive analysis are a better understanding of what your competitors are doing, what they are offering to customers, and how to maintain your competitive advantage. The findings from this analysis are likely to factor strongly into your own company’s strategic planning. However, this is definitely not the only take-away from the process of analyzing competitors.

Build domain knowledge
Another benefit of competitive analysis involves expanding the knowledge base of those working on your website or web application. The analysis offers information about content and functionality that they have probably not considered. This is especially true for newcomers to your industry and should be fairly common; not everyone will be a subject matter expert. Looking longer-term, this educational process benefits not only the current project, but also any future project in that same industry. My own experience speaks strongly to this, as I have been both an Information Architect –(IA) for a web design firm and a Business Analyst (BA) for a large hospital system. In the IA role, I would be working on six projects with little domain knowledge in any of those areas; competitive analyses definitely assisted in getting to know those industries. As a BA, learning about competitors in the medical field on one project would enhance my performance for the next project.

Identify best practices
Exploring competitor websites offers the opportunity to discover what is working well for them, as well as what is commonly being offered via the Web. For example, if all the competitors are offering specific content and functionality, users will likely expect your site to offer similar content and functionality. If they are absent, users may go to the competitor site instead. It is important to note that user expectations often go beyond just giving the information or offering the functionality, and move into questions of information design and interaction design. In other words, what is the quality of the user experience? Poor implementations are unlikely to result in higher conversion rates.

Depending on the budget for the project and what questions we are trying to answer, I may conduct user testing of the competitor websites/web applications. My goals here are simple: Learn from their mistakes, avoid “reinventing the wheel” in my iterative design process, and find a better implementation from where they left off. If I am working on a design (or redesign) of a massive informational website with hundreds of pages, I might focus the testing on how they labeled and organized their content. Alternately, for a website with lots of transactional processes, I would focus on how they approached those tasks.

Expand the dialogue and the possibilities
The final benefit comes from expanded dialogue within the development team, and with other units in your company, about what competitive data means to your strategic direction. Such dialogue can open up new options that would not otherwise have been considered. Competitors may be taking various approaches to reaching the customer base, so multiple possibilities exist. In this situation, a completely novel approach might be best, since no standard is emerging.

The softer side: qualitative data

Data from the analysis will invariably be a mix of quantitative (numerical) and qualitative (non-numerical) information. Each serves a valuable role in a competitive analysis.

High-level inventories
One of the first things I create for most competitive analyses is a high-level inventory of content and functionality. Broadly speaking, content refers to informational pages while functionality is what users can do while they are at the website. A question of granularity always arises with these inventories, since multiple levels of analysis are possible. I would recommend against conducting a low-level content inventory of the competitor websites, in which you track all pages and record their URLs, names, metadata, evaluate them for being ROT (redundant, outdated, or trivial), etc. Such analyses are extremely time-consuming, and your goal is not to redesign the competitor website. Instead, I recommend a high-level inventory in which you record names of pages or functionality and provide a brief description or summary of key information (e.g., search is scoped by product category; search results display whether item is in stock). These high-level inventories produce charts that allow quick comparisons:

Comparison of functionality across competitors

Labeling and taxonomies
For projects involving hundreds of pages, the focus would expand beyond the inventory to analyzing hierarchy and labeling. User testing can provide invaluable insights into how these labels are interpreted and whether the competitor’s taxonomy is working for users. If user testing is not conducted, a confirmatory card sort can be conducted to determine if users would place content in the same areas as the competitor websites, given the same labels and organizational structure.

Visual style
The graphic design of the competitor websites/web applications sets an immediate tone for the user experience and communicates professionalism, credibility, and usability. Typically, I include screenshots of the home pages in the competitive analysis, noting information such as the appearance of horizontal scrollbars at certain resolutions as well as amount of vertical scrolling at common resolutions (e.g., 800×600). Additional screenshots, usually of notable (both good and bad) design practices, are also included as necessary.

Strengths and areas for improvement
A useful starting point for identifying strengths and areas for improvement can be user experience heuristics. While a competitive analysis is not intended to replace a heuristic evaluation, these heuristics can prove to be a helpful starting place and also offer a structure for presenting findings and recommendations. Various lists of heuristics are available, including a list of usability heuristics by Jakob Nielsen as well as interaction design principles from Bruce Tognazzini.

The heuristics that I typically use are:

• Efficient Navigation
• Organizational Clarity
• Clear Labeling
• Consistent Design
• Matching User Expectations
• Effective Visual Design
• Supporting Readability & Scannability
• Facilitating User Tasks
• Providing Help

The strengths become discussion points and possibilities for emulation and improvement. Areas for improvement put the focus on competitive advantage, as they represent competitor shortcomings as well as pitfalls to be avoided. Screen captures can be helpful in showcasing both the good and the bad aspects of competitor implementations.

Crunching the numbers: quantitative analysis

Rankings and ratings
One approach in the quantitative analysis is to rank and rate competitors. Competitors can be assigned a score for each of the heuristics, which then results in individual and aggregate measures of the user experience for comparison purposes. For redesigns, this data can prove to be valuable when ranking your existing site/application and then ranking the new site/application. How do they stack up to the competitors? Has the user experience score improved with the redesign?

User performance
If user testing is conducted, various metrics can be assessed. These include time on task, number of clicks to destination, path to destination, errors, and success rates. As with the rankings and ratings, if the project is a redesign, the comparisons to the existing version and the new version can prove quite useful.

Search engine positioning
A final area for analysis is ranking in major search engines, which could expand into an examination of marketing efforts by the competitors. There should be a set of common keywords for companies in the same market space, and top placement is a definite advantage in attracting new users.

Writing the competitive analysis

Competitive analyses can take a variety of forms and vary in their content, depending on the project, the questions you are trying to answer, and the resources available. Most will contain an executive summary, prioritized recommendations, lists and charts of findings, and appendices with raw data (e.g., if user testing occurred).

For a recent competitive analysis involving a website with nearly a thousand pages and limited functionality, the report focused on comparisons of content and functionality for the top four regional and national competitors, with the analysis revealing that competitors offered significantly greater functionality in the areas of search, online giving, forms to request services and information, and content enhancements such as print-friendly versions of pages and glossary entries integrated with the text content. The best way to convey this disparity in functionality was through charts that showed at a glance how much more was being offered by the competitors. Recommendations focused on expanding functionality to close this competitive gap.

Other competitive analyses have focused more on usability and interaction design, with visual design also factoring in strongly. These analyses tend to be for web applications, which often have the most to gain from exploring how competitors approached a design problem or a user task/process. In some cases, the analysis could become quite narrow if the goal was to isolate a specific user task and optimize the process for that task.

I encourage you to keep an open mind as you conduct a competitive analysis. Each project is unique and will benefit from asking different questions of the competitors. Determine what information will add value and then see if that can come from the analysis.

Sample Deliverables

(Added on 02/28) Thanks to our reader’s comments, we’ve included deliverables for:
# “Music Store”:
# “Medical Center”:

Crafting a User Experience Curriculum

by:   |  Posted on
“During the curriculum development process I was forced to examine my own perceptions of the user experience industry and address a number of important questions about how to teach user experience.”

It isn’t often that one has the opportunity to create a course about user experience, let alone an entire sequence of user experience courses. My opportunity came when the Internet Professional (INP) program at Washtenaw Community College (WCC) in Ann Arbor, Michigan restructured its curriculum. As a faculty member in the INP department and the resident user experience expert, the task naturally fell to me. During the curriculum development process I was forced to examine my own perceptions of the user experience industry and address a number of important questions about how to teach user experience.

The need for a new INP curriculum

During the 2002-2003 school year, major changes were underway in the INP program. Since 1999 the program had focused on training web professionals in either a Design track (focused on web graphic design, animation, and audio/video) or a Technical track (focused on web programming, databases, and server setup). User experience was taught in one core course included in both tracks. This course teamed user experience with project management concepts; needless to say, this approach was not doing justice to either topic. The curriculum had other problems as well. It took too long to complete and was very rigid in its sequencing, which made it practically impossible for faculty to change or add classes.

Taking those concerns to heart, we designed a new curriculum requiring less time and giving students much more flexibility in choosing an educational and career path. All students complete six courses in the Web Technology certificate, covering the fundamentals of web coding, graphic design, user experience, and project management. Then students can choose to pursue one or more advanced certificates: Web Professional (an advanced generalist in the areas noted previously), Web Graphic Design (Photoshop and graphic communication), Interactive Web Design (Macromedia Flash and audio/video), Web Application Developer (programming and databases), or E-Business. Any advanced certificate, combined with electives and general education classes, can then lead to an Associate degree (see Figure 1).

Figure 1: Structure of Redesigned INP Curriculum

The market: understanding industry needs

Every occupational program at WCC has an advisory committee comprised of professionals from the relevant industry. The INP advisory committee has a diverse membership, including web developers and managers from local web design and information technology companies, freelance information architects, and web development staff at the University of Michigan. Periodic committee meetings enable the INP faculty to stay informed about the latest industry developments and employer requirements. A consistent recommendation from the INP advisory committee was the need to train generalists: individuals who could code the front end, work in Photoshop to some extent, and also create site architectures as part of planning a good user experience. What is interesting is that within the information architecture (IA) discipline there has already been discussion about “giving away” IA, in the sense of training other web development team members how to do IA because not all organizations can afford a separate IA specialist. The INP advisory committee was confirming this trend.

The idea of training a generalist led directly to the creation of the Web Technology certificate, which includes the introductory user experience course. Beyond training the generalists desired by industry, the six courses also expose students to various aspects of web development so they can learn what appeals to them and where they might like to extend their training.

The users: understanding student needs

A question I sometimes receive is why an advanced certificate does not exist in Web User Experience. The simple answer is that almost no students would pursue that advanced certificate. Perhaps that sounds harsh, but it reflects a fundamental truth about community colleges and their students: the students want a certificate or degree that will get them a job.

Jobs in the web user experience field typically require at least a Bachelor’s degree. Often a Master’s degree is recommended, if not required. Some students will transfer to a four-year school for a Bachelor’s degree, but others are just interested in earning a certificate or an Associate degree, learning enough to change careers, or just taking some classes for their own personal enrichment. In short, few students are on a track that will take them into a career as a web user experience professional. Students find it easier to gain employment as a programmer, graphic designer, multimedia specialist, or project manager after graduation.

Other complicating factors are that user experience work delves into the abstract and conceptual, requires critical analysis to resolve interface and interaction problems, and involves a number of written deliverables. Taken collectively, those are not enjoyable activities for many community college students. Compare the ambiguity present in resolving a user experience problem to resolving a coding problem or a graphical issue with a Photoshop mockup. The phrase “it depends” frequently accompanies user experience recommendations, while solutions for coding or graphic problems tend to be more clear-cut and obvious. Yet these future coders and graphic designers need to understand the basics of user experience so they can step into a more advanced role or communicate effectively with the user experience professional on their team. Therefore some exposure to user experience concepts is both necessary and valuable.

Structure, organization, and labeling: not just for websites

In structuring the new INP curriculum, we decided to offer three different user experience courses to accommodate learning at each level of the program (certificate, advanced certificate, Associate degree):

  • Web Technology Certificate: Designing User Experience I
  • Web Professional Advanced Certificate: Designing User Experience II
  • Associate Degree: Designing User Experience III (as an elective for the Web Professional and E-Business paths to the Associate degree; E-Business also has Designing User Experience II as an elective)

With this structure every student, regardless of career goals, takes Designing User Experience I. Students pursuing the Web Professional advanced certificate also take Designing User Experience II. If they continue on to the Associate degree, then Designing User Experience III can be taken as an elective. E-Business students can choose both Designing User Experience II and III as electives toward the Associate degree. The Designing User Experience courses must always be taken in the sequence indicated by their numbering.

Choosing a name for these courses proved more difficult than expected. The goal was to arrive at a cross-disciplinary, umbrella label. We needed a label that would encompass the following disciplines:

  • Human-Computer Interaction / Usability
  • Information Architecture
  • Information Design
  • Interaction Design

Because the material is inherently interdisciplinary, using a single discipline’s name for the courses was too limiting. We also wanted the label to endure over time; new disciplines should be able to fit under the label. The two umbrella terms given serious consideration were “User Experience” and “Experience Design.” To emphasize the creative, active nature of the work we wanted to incorporate a verb (which would also make the course name more engaging). This eliminated “Experience Design,” because “Design” complicated the phrasing. Ultimately we decided on “Designing User Experience,” a label that is broad in scope and suggests a creative, active process.

Unfortunately, this label is not obvious or descriptive enough for those outside the industry (including most students). This became apparent when the courses went through the WCC curriculum committee for approval. The curriculum committee is comprised of faculty from across the college. None of the committee members knew what “Designing User Experience” meant, although the course descriptions did help them understand what subjects were being taught. Although the curriculum committee recommended that a different course name be used, the members could not come up with any other suggestions. (The INP faculty had already been down that road before, so we were not surprised.) We assured the curriculum committee that employers would recognize “Designing User Experience” and that this was what really mattered.

The fundamental concepts: Designing User Experience I

What user experience information is most essential? What core user experience concepts and skills should be conveyed to every member of a web development team? As I pondered these questions, it occurred to me that I was missing something important. I was forgetting that user experience is not just about concepts and skills, it is also about perspective. I needed to teach the students to think like user experience professionals. In fact, I needed to do that first, because this would make it easier for the students to acquire the necessary concepts and skills.

The course starts by looking at the web user experience profession, its various disciplines, and how user-centered design is conducted. The next topic is user research methods, followed by an examination of user personas and then a look at assessing client needs. While the information provided up to this point is valuable, the students have not really started thinking like user experience professionals yet. That opportunity comes with the first deliverable, a competitive analysis. Students choose one of two fictitious clients and examine three competitor websites in the chosen industry. The students document each site’s content and functionality, and critique it, identifying strengths and areas for improvement. The feedback from students has been consistent from semester to semester:

“I never looked at websites that way before.”

“I didn’t realize there was so much to think about with a website.”

This project is an eye-opening experience and, most importantly, a perspective-changing experience. For most students, it is their first time critiquing and analyzing a website. During the rest of the semester the students create additional deliverables, including diagramming an existing website and redesigning the interface of another website. The redesign entails critiquing the website’s interface and creating home page and sub-page wireframes resolving the current interface issues. These later deliverables help the students continue to evolve in how they perceive websites.

The additional content and activities in the course are mostly drawn from information architecture, as that discipline focuses on fundamental website concepts. The other topics include:

  • Organization
  • Labeling
  • Card sorting
  • Site diagramming (coinciding with the deliverable mentioned previously)
  • Navigation
  • Interface design (also coinciding with a deliverable)
  • Search (within-site and search engine optimization)
  • Content design (e.g., writing for the web, link colors/text colors, fonts, etc.)

Choosing a textbook is often a difficult process, but given the emphasis on information architecture it seemed only appropriate to use the second edition of Rosenfeld and Morville’s Information Architecture for the World Wide Web .

The class is scheduled in 3-hour blocks, with one meeting per week for each of the 15 weeks in the fall and winter semesters. The class is split into two shorter meetings per week in the 10-week spring/summer sessions. The class sessions follow a standard sequence, beginning with a lecture that includes concepts, numerous examples, and class discussions. Collectively this first part takes approximately an hour and a half. After a short break, the students spend the rest of the class time working either individually or in small groups on an activity related to the day’s topic. At the end of the class time, we discuss the results of the activity and students informally examine and critique the work of their peers. For certain topics (such as card sorting) the lecture time is quite short, with the bulk of class time given to performing exploratory (open) and confirmatory (closed) card sorts. The materials are prepared for the students ahead of time. This sequence of lecture, activity, and wrap-up is used for the other two Designing User Experience courses as well.

The challenge with this class structure is deciding on the proper scope of material for the lecture (so as not to go past the halfway point of the class session), as well as developing activities that fit into the time available in the second half of the class session. All lectures are done in PowerPoint and I provide hard copies of the slides (three per page) to the students at the start of class to reduce the amount of writing they need to do during the lecture portion. I have found that anywhere from 35 to 40 slides is usually ideal, but it depends upon the pacing of the lecture, the number of screenshots and examples, and the amount of discussion in a given group of students—some classes are quiet, others ask lots of questions. Students have asked to have more time for presenting their work at the end of class and giving each other feedback. Unfortunately, the limit of 3-hour limit makes it difficult to fit everything in and I view the concepts presented in the lectures as the highest priority since they inform the activities. As with many aspects of user experience, such decisions are always a balancing act.

The “methods” class: Designing User Experience II

Although Designing User Experience I contains a fair number of methods and deliverables, I tend to think of it as a “concepts” class because one of its main goals is to communicate fundamental concepts. Designing User Experience II is a different matter entirely. Students come in knowing the fundamentals, so now the focus is on methods and preparing students to be user experience professionals. The analogy I use with the students is that of a repair person with a toolbox: they are filling their user experience toolboxes with all sorts of useful “tools” (skills), to resolve any problem they encounter and meet the skill requirements of any employer.

In selecting specific methods and deliverables I found myself moving away from information architecture and engaging with the other user experience disciplines, perhaps because many of the methods taught in Designing User Experience I were from information architecture. The specific methods in the second course include:

  • User testing (usability testing)*
  • Walkthroughs
  • Usability inspection (expert review or heuristic evaluation)*
  • Task analysis*
  • Storyboarding*
  • Style guides*
  • Thesauri and controlled vocabularies
  • Facetted classification
  • Accessibility inspection (expert review or heuristic evaluation focused on accessibility issues)*

* Students work in teams to complete these as deliverables. Task analysis, storyboarding, and style guides are completed together as part of a comprehensive redesign.

You may wonder why accessibility wasn’t mentioned for Designing User Experience I. The primary reason that course did not include a full lecture on accessibility was space limitations; there was already a lot of material to cover. Since a full lecture could not be devoted to the topic, accessibility recommendations were included in the other Designing User Experience I lectures. In Designing User Experience II, the topic is given two full lectures and placed in the broader context of Universal Design, so any shortcomings from the prior course are addressed.

Since the students are developing into user experience professionals, I also have them research and present on a topic from the user experience field. This could be a method not discussed in class, a variation on a method we have covered, or simply the latest and greatest technique on the user experience block. The process of choosing a topic and researching that topic offers the biggest payoff, as students start reading the user experience blogs, joining the email lists, and interacting with those in industry.

No book on the market did a thorough job of explaining all the methods, so I opted for a book that did an excellent job with one method. That book was Steve Krug’s Don’t Make Me Think: A Common Sense Approach to Web Usability—definitely the most enjoyable book I have ever assigned in a class and an excellent introduction to user testing.

Domain-specific best practices: Designing User Experience III

So what is left after teaching user experience concepts and methods? Actually, a fair amount of material remains that is specific to a given type of website or some specialized situation in user experience. These domains and specialized areas include:

  • E-commerce
  • E-government
  • E-healthcare
  • E-learning
  • Intranets
  • Extranets
  • Personalization
  • Internationalization
  • Small interfaces (e.g., hand-held devices)
  • Form design

Assignments focus on critically evaluating how existing websites adhere to best practices, finding solutions beyond the current best practices, and prototyping interfaces in a specific domain. As with the second course, I found that it was difficult to locate an effective textbook covering this breadth of topics. With no solid options I decided to use only online readings and to eliminate the textbook entirely.

“Soft” skills and critical analysis: trying to teach what is difficult to teach

One of the biggest challenges in teaching these courses is conveying what it is like to work in industry and what is needed to succeed. I draw from my years of experience as an information architect and freelance user experience consultant, and provide numerous anecdotes and lessons learned. Even so, it can be hard to communicate all the real-life challenges: how to convince stakeholders to fund user experience, get recommendations implemented, and defuse the tensions that can arise between different team members (e.g., graphic designers and user experience professionals) over the website design/interaction.

While professionalism is always stressed in the deliverables, having well-designed and well-presented deliverables only goes so far in getting them accepted and implemented. It is more difficult, for example, to teach students how to approach a given political context in an organization or how to “seal the deal” for user experience work by convincing high-level stakeholders of the potential for a return on investment. I tell students a number of things not to do (e.g., getting buy-in at just one level of the organization, rather than at both the implementation and decision-making/managerial levels), but a list of things “not to do” is never going to cover all the possibilities. Ultimately the best teacher is life experience, so we stress group work for the in-class activities and the Designing User Experience II deliverables. There is also a capstone INP course where students work in teams to develop websites for real clients, which provides a great deal of insight into team processes and how to work with clients.

A final aspect that is difficult to teach in these courses is critical thinking and analysis. Not every student comes in with the critical thinking skills necessary to analyze a website, so the initial deliverables in Designing User Experience I can be quite difficult for some individuals. We are requiring them to change their perspective on websites as well as to become an analyst, which can be a lot to accomplish in a short period of time. To assist with this, I provide sample deliverables in all three courses, but that can only show students what was recommended in that one situation and how those recommendations were presented. Arriving at recommendations for a different website is a whole new challenge.

Related to the critical thinking issue is an understanding of “good” design. Some students intuitively understand what constitutes good design and so the critiquing and recommendation process is easier. Others can learn what constitutes good design by mastering a set of principles and walking through lots of examples. For others, the sense of good design just never comes together. My colleagues in the Computer Information Systems department often remark that some students just aren’t cut out to be programmers, no matter how hard they try; I believe the same is true of user experience professionals.

Good user experience: not just in the course content

Based on my own experience, my research, student results, and feedback from the INP advisory committee, the three courses we developed prepare students well for employment in industry, assuming they have the requisite critical thinking skills and understanding of design noted previously. Knowing information architecture principles and having a portfolio of IA deliverables landed one student an internship (moving towards a permanent position) with a local web design firm. Another student was hired as a web developer because of her usability inspection of the company’s website. (The employer had requested that applicants come ready to discuss improvements to the website; she went the extra mile by preparing a formal report and got the position over another candidate with a Masters degree). There are other examples as well, including students who have moved up in their companies, in part because of the new skills they acquired.

Another positive is that the progression from concepts to methods to domain-specific best practices introduces topics when students are ready for them, thereby supporting the learning process—and contributing to a good user experience in learning. On a personal level, I can attest that developing and teaching these courses has been an enjoyable and rewarding experience. For those embarking upon a similar course creation process, I can assure you that it will be quite memorable.

Jason Withrow is a faculty member in the Internet Professional department at Washtenaw Community College. He teaches a wide variety of web design classes, including classes on user experience, web coding, project management, and professional practices. He maintains an instructional website, although it is mainly for his students.

Prior to entering the teaching field, he worked in industry as an information architect at a web design firm in Ann Arbor, Michigan. In his spare time he works as a freelance information architect and web designer.

Site Diagrams: Mapping an Information Space

by:   |  Posted on

“To successfully communicate the characteristics of an information space, I needed an approach for creating easily understood diagrams. To be useful to my audience, the diagrams must communicate the “big picture” of the website to stakeholders, while providing enough detail to be useful for the development team.”

Information spaces surround us. When we retrieve a file from our computer, we are browsing through an information space; when we use a search engine we are sifting through an information space; and when we visit a website we are moving through yet another information space. As user experience professionals, it is our job not only to understand how this space works (and how people work within the space), but also how to best access and communicate the information contained therein. Understanding the structure of an information space for a website boils down to the following questions:

  • What is the information structure?
  • How do I visually represent that structure?
  • What relationships exist among the web pages?
  • How are those page relationships represented?

I suspected that site diagrams would be quite helpful in answering these questions. How to create the right diagram became a personal challenge.

The evolution of a diagramming approach

My earliest inspiration came in a graduate class on Information Architecture at the University of Michigan’s School of Information. Our textbook was Rosenfeld & Morville’s Information Architecture for the World Wide Web, which provided me with my first examples of site diagrams. Based on the book’s diagrams, I had an idea of how I could visually convey structural and functional information about a website.

Because the text did not provide specific diagramming guidelines, I found myself iterating from the few images it contained. Every project I worked on served as a further iteration as I adopted practices that worked well and discarded those that did not. During this iterative process, Jesse James Garrett released his excellent Visual Vocabulary, which had a decidedly different focus in its diagramming. Whereas my evolving approach focused primarily on mapping out structure and page relationships, with secondary consideration given to functionality and interactivity, I found that the Visual Vocabulary was ideal for displaying detailed functionality and interactivity and was not the right approach for conveying my structural considerations

To successfully communicate the characteristics of an information space I needed an approach for creating easily understood diagrams. To be useful to my audience, the diagrams must communicate the “big picture” of the website to stakeholders, while providing enough detail to be useful for the development team. A final goal was to avoid unnecessary abstraction in the diagrams; the diagram content should map closely to what will later be observed on the website (or what is currently on the website, if the diagram is part of a redesign). In fact, my desire to understand websites led me to develop a diagramming approach called “structural/functional site diagramming.”

Starting with a site outline

A site diagram might initially sound like a site outline. And while not technically a part of the site diagram, a site outline complements the diagram quite well. The site outline presents the website structure in a typical outline format, perfectly mirroring the numbering, levels, and labels in the site diagram. The advantages of site outlines is that they are faster to create and maintain than site diagrams, but their drawbacks include difficulties showing linear page sequences and limits in their ability to mention functionality and other content types, mainly due to the visual clutter the extra text creates. (If that information is provided it is typically in parentheses following the page name.) Site outlines also do not reveal the “big picture” of the website (such as its breadth and depth) as readily as site diagrams.

After creating the initial site outline, the next step is to represent the information in diagram format, which allows us to more easily show complex page relationships as well as functionality. Since we are moving into the diagramming process, the logical starting place is the structural units that serve as the building blocks of the diagram.

Structural units in the diagram

The basic structural unit of the diagram is the web page, represented by a rectangle. If a web page is dynamically generated then the rectangle’s edges are rounded (static pages do not receive rounded edges). Web pages to be developed at a future date are represented by a dotted rectangle; a footnote can indicate the target date for the page to be available or reference a content inventory for those details. By mapping this future development a site diagram can help predict long-term user interface needs and serves to guide interface design towards a more scalable layout (e.g., a layout that will easily accommodate the four new global navigation buttons that will be added over the span of six months).

Multiple pages at the same level of the website can be clustered, providing a useful level of abstraction in situations where displaying each separate page would prove difficult (usually due to the space limitations of the printed page holding the diagram). When deciding to cluster pages some basic criteria are followed:

  1. The pages being clustered are located no higher than Level 3 of the website; preferably they are at lower levels.
    Clustering at too high a level (e.g., from the home page) will often hide pertinent information and page relationships further down in the website structure. More on this later.
  2. There are no sub-pages under the clustered items.
    Clustering prevents individual paths through the website from being seen, so any value gained from knowing those paths to lower-level pages is lost.
  3. The pages have similar content.
    Executive biographies, press releases, job postings, and discussion board entries all work well for clustering because these are multiple pages with similar content. Given their inherent similarities, showing them separately does not offer enough value to offset the visual clutter they introduce into the diagram.
  4. The quantity of pages is likely to change frequently.
    Rather than change the diagram on a daily basis, it is best to show a cluster.

Figure 1: Structural site diagramming units

Specifying levels and numbering pages

Most websites possess a structure that is at least partially hierarchical. In that hierarchical structure, each page is at a certain level, based on parent and child relationships to other pages within the information space. The home page is Level 1, global navigation and other non-global pages off the home page are Level 2, local navigation is Level 3, and so on. Often each link clicked from “Home” (if a hierarchical path is followed) corresponds to a new level of the website.

It is important to note that these levels represent how the website information is structured conceptually–often from general (high-level pages) to specific (low-level pages). User mental models mirror this conceptual structure. The levels do not necessarily correspond to file location and directory structure; a website could have Level 6 pages when all the website files are in the same directory on the server.

Numbering the web pages is a very helpful way to keep everything organized and simplifies communication about the website. The home page is 1.0 and second-level pages are 1.1, 1.2, 1.3, etc. Third-level pages under 1.1 would be 1.1.1, 1.1.2, 1.1.3, etc. A simple website structure, shown in a site outline format, would be:

1.0 Home

   1.1 Who We Are
       1.1.1 Our History
       1.1.2.Our Staff
 – Staff Bios

   1.2 What We Do
       1.2.1 Products
       1.2.2 Services

Each web page receives just one number and each number is unique; cross-links to that page reference the number. From the number alone we know at least two things about the page: the level at which the page occurs (for example 1.2.2 is a level 3 page, determined by counting the number of digits) and the path to reach that page (1.2.2 is down the 1.2 path in the global navigation). Clustered pages end in .x (e.g., if that cluster is prone to frequent changes; if the number of web pages in the cluster is stable then a fixed final value can be provided.

The importance of numbering the pages cannot be overestimated; there is nothing quite as embarrassing during a client meeting as scrambling to find the relevant diagram and/or documentation for a page based on just its name. This problem compounds as the number of pages increase, and if different pages with the same name (such as “FAQ”) exist in multiple sections of the website. The unique number assigned to each page eliminates those concerns.

Visually mapping the structure

Tree diagrams are used to visually present the structure. The choice of a horizontal tree diagram or a vertical tree diagram (See Figures 2 and 3) usually comes down to a consideration of website breadth and depth as well as the author’s preference for working in portrait or landscape orientation for the printed diagram.

If a horizontal tree diagram is created, the levels of the website progress from left to right, with Level 1 on the left and successively lower levels to the right. Vertical tree diagrams progress from top to bottom, with Level 1 at the top of the printed page and successive levels further down the page.

Figure 2: Horizontal tree diagram

Figure 3: Vertical tree diagram

As a matter of necessity, the site diagram is often divided (chunked) across multiple printed pages (See Figures 4 and 5). The first diagram page contains Level 1 (“Home”), Level 2 (global navigation and other non-global pages off the home page), and the legend. Subsequent diagram pages focus on each Level 2 section that has sub-pages, detailing those areas of the website. Should a given Level 2 section go quite deep (to Level 6 or 7) more than one diagram page may be required. Generally this diagram chunking can only be avoided with small websites (all the content can be shown on one diagram page) or if you have access to a printer capable of spooling output on a continuous sheet of paper.

Figure 4: Chunking a site diagram for easier printing: Page 1 (Click to enlarge)

Figure 5: Chunking a site diagram for easier printing: Page 2 (Click to enlarge)

Linking and page relationships

Solid connecting lines between rectangles indicate standard links moving from a parent to a child page. In practice, these standard links usually occur in a navigation bar or from a link in the text of a page. Arrows are not used to indicate directionality for standard links; the visual flow from higher to lower levels in the tree diagram suggests the usual direction of the linking. The ways in which lines connect and diverge reveals valuable information concerning how navigation functions in the website (see Figures 6 and 7).

Figure 6: All Level 2 pages link to each other (Click to enlarge)

Figure 7: Navigation between Level 2 pages requires a return to “Home” (Click to enlarge)

Linear sequences

For linear page sequences, arrows are often used to signify the flow through the process. In cases where the directionality is more rigid (such as a checkout process) the arrow would be pointing in one direction between the pages (See Figure 8). Situations where linearity is an option, but not a requirement (such as a multiple-page article with both “Previous” and “Next” links and links to all article sections on each page), could be represented with a double-sided arrow between the pages as well as a solid line to which all the pages connect. Linear page sequences are also generally displayed from left-to-right, because the pages stay at the same level in the website structure. To resolve numbering issues (which arise because all the pages are at the same level) it is helpful to use a shared page number and add letters (e.g., a, b, c) to the end of that number for successive steps/pages.

Figure 8: Linear page sequences (Click to enlarge)

Cross links

Cross links are a different matter entirely. Those relationships are represented by dotted lines, generally ending in a rectangle containing the numbers of the cross-linked pages (see Figure 9).

The purest definition of a cross link is a link to a page in a different area of the website (e.g., a link from 1.3.2 to 1.5.3), although in practice links within the same section (e.g., a link from 1.3.2 to are often labeled as cross links, especially if the link traverses multiple levels. Quick links on a home page would be labeled as cross links. In cases where cross links are to pages on the same diagram page, an arrow can be added to the dotted line to show directionality.

External links

External links are represented by a labeled icon in close proximity to the page containing the link (See Figure 9). The placement of the icon outside the rectangle is intentionally done to emphasize that the link is external. Incoming links are shown in a similar fashion, using a special icon placed in close proximity to the affected page; showing such links is a relatively rare practice.

Pages that fit into a given grouping (such as global navigation or a local navigation bar) can have that relationship shown with a dashed box that is given a descriptive label (See Figure 9).

Figure 9: Cross links, external links, and page groupings (Click to enlarge)

Displaying non-web content types

Websites contain a wide variety of content types that do not fit into the “web page” category, including Word documents, PDF files, PowerPoint slides, Excel spreadsheets, executables, archive formats, even images meant for downloading. In this approach the most important difference between web pages and other content types is that the other content types do not receive page numbers. The rationale is that these documents are not part of the website navigation structure, so a number is unnecessary. After all, how often do you load a Word document from the home page in order to navigate deeper into the website? If appropriate, a different identifier (something other than the page numbering approach) could be used to track these content types; such an identifier would likely map to an entry in a content inventory.

What the site diagrams do reveal about other content types is which pages link to them. For example, an icon representing PDF files is added to the legend and that icon is placed inside the rectangles for all pages linking to at least one PDF. The placement inside the rectangle reinforces that this document is available from that web page (See Figure 10). As mentioned earlier, further details about the PDF could be given in a content inventory or perhaps in a footnote. The decision to minimize information about the file (such as the file name, the number of PDFs linked from the page, and any other relevant data) within the diagram is to reduce visual clutter. These tradeoffs between descriptiveness and clutter occur fairly often.

Representing functionality

Broadly defined, the functionality is the scripting and interactive aspects of the website. Forms, email links, within-page links, JavaScript, and server-side languages all constitute website functionality. Visually, this functionality is layered on top of the structural information (See Figure 10). Just like non-web content types, different types of functionality are assigned icons in the legend and those icons are placed inside the rectangles for pages containing the functionality. The one exception is for pages that involve server-side processing; those pages use a rounded rectangle that is also defined in the legend.

Figure 10: Displaying content types and functionality (Click to enlarge)

Adding the metadata

If one thing is certain about site diagrams, it is that they are continually changing along with the websites they represent. Version numbers are quite useful for tracking these changes (accidentally giving developers an outdated site diagram causes all sorts of havoc), as well as dates for when the document was created and last updated. URL and site name are also included and authorship information is important, should questions arise. Labeling the diagram pages and including the section number (e.g., 1.3) for multi-page diagrams also saves time when trying to track down a specific web page inside the structure.

Diagramming in practice

In using these diagramming techniques, it is important to keep an open mind and to be creative. The ultimate goal is to produce a diagram that accurately describes either what has been created or what is yet to be created, and do so in a manner easily grasped by various stakeholder groups.

Given the diversity of structures and functionality in websites, it is likely that at some point a unique situation will arise, one that goes outside the guidelines noted in this article. This happens most frequently when diagramming large websites at the start of a redesign; large structures invariably have odd pathways arising from multiple authors and/or the addition of content over time. In those challenging situations it is best to iterate and innovate, along the way perhaps creating a novel way of representing that structure or interactivity.

For More Information:



Jason Withrow is a faculty member in the Internet Professional department at Washtenaw Community College. He teaches a wide variety of web design classes, including classes on user experience, web coding, project management, and professional practices. He maintains an instructional website, although it is mainly for his students.

Prior to entering the teaching field, he worked in industry as an information architect at a web design firm in Ann Arbor, Michigan. In his spare time he works as a freelance information architect and web designer.

Paradigm Dissonance: A Significant Factor in Design and Business Problems

by:   |  Posted on

“A good listener is not only popular everywhere, but after a while he knows something.”
– Wilson Mizner

“Identifying paradigm dissonance as a source of problems isn’t new, but creating a framework for dealing with this problem in a business and design environment moves this idea in a new direction.”Introduction
How often do we want to simply make our point, instead of bringing our opinions together to reach consensus? Wouldn’t the world be a much better place if we looked beyond our own limited perspective to understand other beliefs, thoughts, religions, passions, and goals? Leaving the issue of world peace to others, we think that this same behavior pattern is happening in design and business. Look at all the PowerPoint presentations and slick brochures: we want to tell our view, instead of listening to others. We want our opinion to be heard. It is precisely this desire to have our opinions be heard and to advance our own perspective that fuels issues of “paradigm dissonance” as attempts to resolve conflicting paradigms that demand compromise and collaboration. Identifying paradigm dissonance as a source of problems isn’t new (for example, look at the fifth highly effective habit1), but creating a framework for dealing with this problem in a business and design environment moves this idea in a new direction.

Defining the key terms
Let’s begin by examining the often incorrectly used terms “mental model” and “paradigm.” According to, a paradigm is a generally accepted perspective of a certain group, whereas a mental model (or cognitive map) is defined as an interpretive framework of the world.


The mental model, it is argued, exists in the human mind and affects actions and decisions as well as knowledge structures. This means that a paradigm is an element within a mental model. In our experience the differences in paradigms among designers, managers, users, engineers, information architects, graphic designers, etc. are a major reason why business and design problems exist.

Exploring the problem
Mid-size and large corporations, as part of their growth over time, divide employees into multiple departments. This employee fragmentation contributes greatly to political games and jockeying for control (e.g., “This is mine. That is yours. Don’t try to tell me what to do with mine.”), while hindering effective communication and contributing to each department feeling like its view is right and the others’ are wrong. The latter issue arises mostly because one department does not understand what the other department is doing and, more importantly, WHY they are doing it. That question of WHY goes back to the differing paradigms.

Hypothetical example: Paradigm dissonance in the workplace2
A manager wants to know things (e.g., about progress, costs, revenues, turnover, etc.). His employees know things (e.g., about that individual order they scored, the problem yesterday that they solved, the payment they arranged, etc.).

If the manager asks his employees about the things he wants to know, his employees mumble and tell him they will deliver the numbers next week. Those employees have to apply some (perhaps many) modifications to what they know to transform that knowledge into the things the manager wants to know.

Up to this point, the problem is clear; it gets complex when assumptions are made about “what one thinks the other wants to know.” This idea about what the other wants to know is completely based on previous experiences, assumptions, and group values and beliefs.

Further complicating the situation, humans tend to make what social psychologists call the Fundamental Attribution Error, which is to blame other’s perceived mistakes on some intrinsic aspect of that person (e.g., their personality or personal abilities: “they must be stupid to have made that decision”) and ignore other possible reasons. These reasons include situational variables driving behavior and also differences in paradigms; in the other paradigm the decision is perfectly logical, but you need to see it from that perspective to know it is logical. Of course, as part of this attribution error we tend to perceive our own actions as being externally driven and not internally driven.

What can be done?
Generally speaking, there are four relevant types of paradigm dissonances: supplier-customer, manager-employee, designer-user, and department-department. Each type or paradigm dissonance involves special considerations that are beyond the scope of the present article, which focuses on ways to resolve paradigm dissonance.

There are three potential approaches to dealing with this problem. On a strategic level, the insights in paradigm dissonance are crucial because those constitute the starting point for all future activities. On a tactical level, understanding is important, but there’s no need to work out all the differences: to indicate and understand them is enough. On an operational level, adjusting paradigms isn’t always possible. Therefore accepting the difference and building a pragmatic link between them seems a good thing to do. The effort in adjusting paradigms is related to the number of people involved and the importance of adjusting the paradigm.


Let’s take a closer look at the different approaches:

1. Strategic: Build a new, shared paradigm
This process is focused on building a common language, which is the starting point for future exchanges. For example, bring the IT, sales and financial departments together. Have them define “customer value” (see also paradigm mapping). In the practice of information architecture, when you want to adjust the design of your website to the paradigm of the visitors, you can execute a click stream analysis or exit survey to learn more about their underlying values and beliefs. Information design practices also come in handy when we want to form a new paradigm for a specified group. These help in discussions concerning what a certain model means to people.


Case study: Implementing a marketing data warehouse platform for a Dutch Bank
After a long time of discussions, meetings, and presentations, the ICT (Information and Communication Technology)3 department still wasn’t able to decide on the future direction for the marketing database. The old data warehouse platform was practically falling apart, and the necessity for change was growing day by day. To solve this problem all involved groups were brought together to define what a marketing database was and what its main functions should be. This was visualized in a conceptual model that both marketing and sales people and ICT people (even the technical architects) could agree upon. This became the new paradigm in which all activities for requirement analyses and functional and technical design could take place. The project was revitalized and development took a major step forward.

2. Tactical: Build understanding of other paradigms
Facilitate interaction among different groups by putting more focus on interdisciplinary departments and interdisciplinary training. The web has been fairly effective at bringing together the graphic designers, programmers, project managers, and user experience professionals and putting them on the same team, which has resulted in a number of paradigm dissonances. Even beyond development team coordination, however, is the issue of understanding the customer’s paradigms. To better understand those paradigms, establish interaction with the customers, for example by installing customer focus groups. Those groups represent the ideal or typical customer and through their interaction with the company website and materials, various aspects of the differing paradigms involved become apparent.


Case study: Paradigm dissonance and distance learning at an educational institution
Distance learning courses (where instruction is entirely “at a distance” and done online) flourished for a number of years at WCC before being suddenly stopped by the administration without consulting the faculty who teach those classes. Discussions revealed not only widely differing paradigms between the groups concerning the nature, value, and appropriateness of distance learning, but also that intra-group paradigms also differed fairly significantly among the faculty concerning this teaching modality. Among the various recommended courses of action was a proposal to form a joint faculty-administration group to study these differences in paradigms and to conduct research on distance learning so that the assumptions inherent in the paradigms could be disproved, if false.

3. Operational: Build bridges between paradigms
Accept differences in paradigms and implement smart ways of dealing with them (Fig 5). For example when confronting the paradigm dissonance between customers and suppliers, build a taxonomy for both and make 1-to-1 relationships (also see the Modular Network Design method, Hoogeweegen et al). For the paradigm conflict between managers and employees, one can implement a management dashboard, based on the existing paradigms in the organization.


Case study: Designing a website for people with disabilities
The Ministry of Health initiated a program to help disabled individuals by giving them insight into the available market of special products. The main question was: “How can the target group find products, if they do not know what they are looking for?” To solve this problem, a functional design of a web portal was created for this special group, where they could specify their disability in the International Classification of Functioning, Disability and Health (the ICF). This “taxonomy” matched their paradigm by identifying the functions that could not be executed given specific disabilities. The suppliers of special products for the disabled however, had their own paradigm: the ISO999 standard.

To bridge the gap between the paradigms links were established between the two standards, with ongoing assistance from a variety of medical specialists. Disabled users can now visit the web portal and identify their type of disability (e.g., that they have problems seeing and they want to read) and learn about all the products that can assist them (e.g., glasses, magnifiers, large letter-books, etc.).

Future directions
Dealing with differences in paradigms is fairly new and is a field worth investigating. In our experience it is the source of many business issues, for example: unsuccessful implementations, inefficient business processes, and design problems. An important first step is to visualize the differences in paradigms, so that the process of connecting paradigms, establishing new paradigms, or building understanding of other paradigms can begin. Through visualization the process moves beyond just talking about the differences, which is often not enough, because all the issues and relevant elements are interrelated and, to some extent, are locked in place. Visualization offers a unique shared starting point and valuable framework for moving forward.


  1. The fifth habit: First seek to understand, then to be understood. Adapted from The 7 habits of highly effective people, Stephen R. Covey
  2. Case studies are based on the experiences of the two authors.
  3. “ICT” is a Dutch term for “Information and Communication Technology” and is used in the same way as “Information Technology” (IT).

Web Resources

Cognitive Psychology & IA: From Theory to Practice

by:   |  Posted on
“Theories exist to be tested and disproved, so that more accurate theories can then be devised.”What do cognitive psychology and information architecture have in common? Actually there is a good deal of common ground between the two disciplines. First and foremost, both are concerned with mental processes and how to support those processes. Indeed, many information architects (including the author) have backgrounds in cognitive psychology or a closely related field. Certainly, having a background in cognitive psychology supports the practice of information architecture, and it is precisely those interconnections and support that will be explored.

Before delving into the details of how cognitive psychology informs information architecture, it is important to keep a few considerations in mind. The first is that psychological science is not “perfect” in the sense that all the significant variables influencing human behavior are known. Theories exist to be tested and disproved, so that more accurate theories can then be devised. A second consideration is that cognitive psychology focuses on theory and research, while the field of information architecture has tended more toward the practitioner side. A third consideration, perhaps the most important one, is that translating research results and theory to industry practice is, at best, an imprecise process. In fact, misapplication of research findings is a very real possibility—an example, given later, concerns misapplication of research on short-term memory.

Mental categories
From the user’s perspective, a mental category is a grouping mechanism, a way to bring together items or concepts through some unifying characteristic(s) or attribute(s). So what are those characteristics or attributes? This is where it gets interesting (and challenging) for the information architect because there are various ways to create categories and certainly no “right” set of categories to use.

In fact, from one user to another, the categories may differ significantly. Some categories are formed on the basis of visual similarity (e.g., this looks like a laptop computer, so it goes in my “laptop” category), while other categories could be based on items serving a shared purpose (e.g., software involved in web design). The items in a category could even be based on a set of rules for inclusion and exclusion (e.g., if there are no geometrical shapes, this cannot be a site diagram). Cultural differences, socialization, and cohort effects (differences based on when someone was born) also factor into the categorization process, creating even more diversity in how categories are formed.

Given that there are so many possible approaches to categorization, what is an information architect to do? The best advice is to try to accommodate as many different categorization approaches as possible, ideally supporting the most common approaches while realizing that accommodating everyone is impossible. In most cases websites just support one categorization approach for content, which puts the burden on the user to try to work within that approach. If the adjustment cannot be made, it is likely to be quite a frustrating experience. An example of this situation would be the use of categories specific to a given corporate culture; those outside the company would likely have a difficult time following the categorization scheme.

Open-ended card sorting is a very useful tool for studying mental categories and exploring why some categories are formed and others are not. Allow the user the freedom to freely sort the content cards, forming groupings and sub-groupings as necessary. If given the choice between sitting down with the user doing the card sort and taking notes, or letting the user complete the sorting using card sorting software, go with the face-to-face interaction. The software will likely perform a cluster analysis and reveal statistical groupings, but it is unlikely to record what the user said at a given moment, why groupings were made, or what groupings were perhaps created initially and then changed later. Those insights are invaluable when trying to understand mental categories.

Based on the card sorting, numerous approaches to categorizing the content are now apparent. How can these approaches be supported in the same interface? One answer is through the use of facets in browsing and searching. Both the Epicurious website and the Flamenco image search provide excellent examples of how a facet-based approach can be implemented. Search engines can also support this diversity of mental categories by clustering results based on facets. Of course, the trade-off here is that categorical metadata needs to be developed and applied to the documents, so significant time and resources must be available. The advantage, however, is that the users can now browse or search based on the facet closest to their way of mentally categorizing the content. Choice is returned to the user.

Visual perception
Visual perception also factors into the user experience because visual cues are often the basis for mental associations users make among items on the interface. The Gestalt psychologists explored how visual perception works, isolating a number of rules that explain how the human perceptual system functions. The two rules most pertinent to the Web are proximity and similarity.

The Gestalt rule of proximity indicates that items close together are perceived as being related/associated:

Proximity suggests two statements, not one.

Proximity suggests three columns, not five rows.

The Gestalt rule of similarity indicates that items with a similar appearance are perceived as being related/associated:

Similarity suggests two statements, not one.

Second and fifth rows perceived as distinct rows.

The implications for navigation bar design are apparent, since navigation items that are across the page and appear dissimilar are unlikely to be perceptually associated. There are also important implications for the display of local navigation bars, which need to have their items be proximal and similar so that users perceive them as being together. They must also be associated with the appropriate section in the global navigation bar (and not be perceived as global navigation).

Most of your users should perceive the desired relationships if proximity and similarity are used appropriately. Wireframes and prototypes work quite well for testing your implementation of the Gestalt rules, providing low-cost options for improving visual design.

Memory is one of the primary domains examined by cognitive psychologists, since encoding, storage, and retrieval of information constitute a significant portion of our cognitive activity. Unfortunately, research done by cognitive psychologists on memory has not always translated successfully (or correctly) to information architecture practice. The best example of this is research on short-term memory, which established that humans can hold from five to nine chunks of information in short-term (temporary) memory.

Based on this research, some practitioners claim that navigation bars should not be longer than nine items. There are a number of flaws in this thinking. The first flaw, and the most important, is that global navigation is meant to be present on every page and that local navigation is meant to be present on every page within a given section of the website. Where is the need to commit the navigation bar to memory, if it is always there? Are users closing their eyes and trying to recall everything on the navigation bar? Of course not.

Another flaw is that applying the research to navigation bar length is akin to comparing apples and oranges; they are different settings. Navigating a website involves far more visual stimuli and interaction than the research tasks, and website content is familiar enough to fit into established semantic networks, unlike research content that is often random or nonsensical.

This is not to say that short-term memory (or other proposed players in memory processes, such as working memory) never comes into play. It just doesn’t come up based on the length of the navigation bar. Short-term memory becomes important when navigation bars disappear in the lower levels of a website, or when a link takes the user to an entirely different part of the website. At that point the user wonders: How did I get here?

And where is here, exactly? If navigation bars cannot be maintained at lower levels (perhaps because of interface constraints), short-term memory can be supported through the inclusion of breadcrumb trails, providing descriptive page title information and giving the page a descriptive and visually prominent heading/name. Efforts can even be made to visually denote a section of the website, such as using a certain color or graphic for pages within a section, which serves to remind users of their current location.

Excessive numbers of items in a navigation bar does potentially tax mental resources, but the issue here is one of information processing (not memory/storage) and the ability to visually scan and differentiate the “signal” (the desired item) from the “noise” (all the surrounding items). To reduce the noise, the use of headings in the navigation bar to group links is recommended. The Microsoft website uses such headings to good effect. Users can scan a smaller number of headings before scanning within a given grouping of links. Using this approach, navigation bars can grow comfortably to much larger sizes. Boldfacing the headings further supports scanning, as they “pop–out” from the surrounding links.

When a user is scanning through a list of links, trying to decide which one is best, that decision-making process brings in another type of memory: long-term memory. As the name suggests, long-term memory is storage for the long haul. Whether or not information is stored there permanently is still up for debate. Our problems remembering something could be because that information decayed and was lost, or it could be that the information is intact, but our ability to retrieve it is hampered by interference from other information. Whatever the case, our interest is in how memory networks are conceptualized. Those conceptual models give us insight into how users structure and associate concepts.

One approach to conceptualizing these is through semantic networks, or networks of meaning. Based on our experiences and learning, the nodes in these networks (which represent concepts or items) are linked together, forming an intricate network of interrelations.

As labels in the navigation bar are visually scanned, various nodes are activated in the network. Activation of one node triggers activation of connected nodes, which then trigger their connected nodes, spreading outward in a weakening wave until the strength of that activation is spent. This spreading activation helps explain how thinking of one topic can bring to mind related topics. Spreading activation also helps to explain how users struggle to decide between two or more navigation links that “both sound good” or who give up and say “none of these look right.” In the former case, the spreading activation patterns for the labels could have both seemed equally promising (they both activate the desired node at about the same strength), while in the latter case the desired node was never activated.

Closely related is the concept of information scent, as users could be evaluating labels based on their semantic networks, attempting to locate the label with the best “scent” (i.e., the label most closely related to the desired node in their semantic network). Card sorting is again useful in exploring (albeit in a limited and indirect way) the various semantic network structures established by users. Open-ended card sorts, where users freely sort cards into groupings and sub-groupings, help to establish which nodes are most closely interconnected. Closed card sorts, where users have to place content cards into predefined categories, help determine whether the information scent of the category labels is adequate, while also giving insight into how their semantic networks are structured. User testing is also extremely useful in determining whether information scent is correct and whether labels need adjustment.

A primary concern is with a little phenomenon called transference. No, this is not related to how you got along with your mother and how that influences current relationships. This is cognitive psychology, not counseling or clinical psychology.

Transference, in this context of learning, refers to our expectations about an interface’s behavior based on our previous experiences with other interfaces. How do we know the way a scrollbar works? That knowledge is based on previous experience. What do the icons in a toolbar represent to us? We make inferences based on our experience with other software that uses the same or similar icons. Trying to distinguish which navigation bar is global or which is local? We use what we have learned on previous websites to identify where those navigation bars tend to be located. If someone has to switch back and forth between Windows and Macintosh operating systems, sooner or later they will try something that only works in Windows on the Mac or vice versa, simply because of transference.

When our expectations turn out to be correct, the effect is one of positive transference. What we learned from the previous interface transferred successfully to the current one. Negative transference occurs when our expectations are incorrect; this process tends to result in an error. On websites, the transference typically involves layout choices, how links and buttons function, what certain labels and icons mean, and how technology used by the website functions. Websites with frames, for example, can pose negative transference issues, as users unaccustomed to frames may be confused about how printing functions and why bookmarking will only work for the homepage. In addition, the multitude of interface options offered by Dynamic HTML and Flash may be beneficial or harmful, depending on whether positive or negative transference occurs. Certainly, the effects of transference should always be considered in labeling and interface development.

A broadened perspective
Consideration of mental categories influences how content is organized, while factoring in visual perception, memory, semantic networks, and learning helps to guide labeling and interface decisions. Considering research and theory in cognitive psychology helps information architects create better user experiences, if only because it helps us ask more, and better, questions about what creates a good user experience.

Jason Withrow is a faculty member in the Internet Professional department at Washtenaw Community College. He teaches a wide variety of web design classes, including classes on user experience, web coding, project management, and professional practices. He maintains an instructional website, although it is mainly for his students.

Prior to entering the teaching field, he worked in industry as an information architect at a web design firm in Ann Arbor, Michigan. In his spare time he works as a freelance information architect and web designer.