Navigation Theory and Practice at

I consider information architecture and navigation development to be one of the most important parts of my job. There are over 300 individual websites related to the University at, and for some users the homepage ( is the only way to get around the website.

When modifying the top-level navigation for any site, here are the considerations I make:

  1. How is my audience grouped and which group is primary? What are the primary tasks of each group?
  2. How has the content been organized in the past?
  3. What navigational structure will be used?
  4. How will organizational hierarchy affect navigational hierarchy?
  5. What are the constraints imposed by the design or theme?

Users and Tasks

Building an effective website must begin with an adequate understanding of users (who they are, what they’re like) and tasks (what are they trying to do, what do we want them do). For the University homepage, the audiences are defined by task-based constituencies: prospective students, current students, alumni, prospective employees, faculty, staff, community members, and other visitors. Within each of those groups, it’s important to consider and respect all kinds of user behavior.

The primary audience for the homepage is prospective students. Their primary task on the website is figuring out if they want to come to school here; our primary goal for them is to apply. There are many more tasks and goals defined for each audience, but there is only one homepage and one top-level navigation (however with a portal this would change). We use the list of users and tasks to test the site for usability.

Past Architecture and Iterative Design

Change to the design or interaction can be very disconcerting for most users, so it’s important to consider what they are accustomed to and build from there. There is no longer any such thing as starting over–if a new design or architecture is desired, change in that direction must be iterative to be effective.

In the past (from Fall 2000), the homepage had this top-level navigation:

  • Colleges/Programs
  • Athletics
  • Information Technology
  • Administration
  • Giving (added Fall 2002)
  • Library (added Fall 2002)
  • News/Events (changed from “Newsletter” in Fall 2002)
  • Search

In the Spring of 2006, the top-level navigation transitioned to:

  • Admissions
  • Academics
  • Outreach Programs
  • Giving to UALR
  • Athletics
  • Jobs at UALR
  • Financial Aid & Scholarships
  • Libraries & Collections
  • Administration

Today, or since Spring 2009, the navigation is:

  • About UALR (contains Jobs and Administration)
  • Academics
  • Admissions
  • Financial Aid & Scholarships
  • Libraries & Collections
  • Research (in Summer 2009)
  • Outreach Programs
  • Giving to UALR
  • Contact UALR

Organizational Hierarchy

Most users have no idea how the university’s departments are structured in our organizational hierarchy. In a previous architecture, users were directed to “Colleges and Programs” which contained a list of departments. Users, especially prospective students, often had trouble finding information about particular programs under this structure (e.g. users would not know to look for information about sign language under the Department of Counseling, Adult Rehabilitation and Education, let alone the College of Education). Today the listing of programs is separate from the listing of colleges and departments. Web Services has plans to make both of these more dynamic and useful.

The reality that programs are contained within departments is purely contextual. Organization hierarchy can affect how content is written and manged, but should not negatively affect user experience.

Design Constraints

As far as developing a navigation structure goes, there are two basic strategies: deep or shallow. A deep navigation displays fewer links at a time forcing the user to “drill down” to the content that they desire. A shallow structure displays many links at once. In most circumstances, either system takes the user a similar amount of time either by click click clicking to get to content, or searching through a bunch of links to find the right one.

Web Services, in most cases, prefers to use a deep navigation structure over a shallow one. We recommend between 5 and 7 top level links on any given site which usually makes it easier to classify content into a hierarchy and build new sites at appropriate levels within that hierarchy. The tools we currently use—WordPress mainly—is easier to manage with this structure. WordPress, and more specifically our site design and current implementation of the tool, is limited to three levels of hierarchy and a homepage (per site).

Our current top level navigation area will max-out at 9 links. I regularly monitor the traffic on these links for trends and to evaluate the usefulness of each one, however links with poor traffic do not always get taken away (e.g. “Giving to UALR”).

Future Directions

Can a navigation be shallow and deep at the same time? I’m interested in providing context for each high-level link. This will be even more crucial the more vague our links are (e.g. “About UALR”). To do this I’d like us to consider enhancing our primary navigation with a fly-out menu to help provide some context, increase usability, and get users to their destinations faster.

As always, I’m willing to discus changes to the navigation. My position is to do what’s best for the primary user experience.

Read more about subsite structure usability, the usefulness of navigation, and internet information architecture and usability from Jacob Nielsen.

Posted in: Discussion

Comments are closed.