User Centered Design Basics - w-edge.com User_Centered_Design_Seminar_071… · User Centered Design Basics OSU CFAES CommTech – User Centered Design Basics Page 3 of 30 Version

Business solutions through information technology

User Centered Design Basics

OSU College of Food, Agricultural, and Environmental

Sciences CommTech Division

If you have received this document by mistake, note that the reading, the reproduction or the distribution of this document is strictly forbidden. You are hereby requested to inform us by telephone at (614) 228-2245 and to return this document by certified mail.

Version 1.0 July 12, 2007


OSU CFAES CommTech – User Centered Design Basics Page 2 of 30 Version 1.0, July 12, 2007

1 Introduction ................................................................................................................. 3 2 What is User Centered Design? .................................................................................. 3 3 Getting to know your users ......................................................................................... 4

3.1 Design Strategy ............................................................................................... 4 3.2 What information should I gather about users? ............................................... 4

3.2.1 User’s mental model ............................................................................ 4 3.3 The value of profiles and personas ................................................................. 5

3.3.1 Profile Example: ................................................................................... 5 3.3.2 Persona example (includes environmental profile information): .......... 5 3.3.3 Task Profile Example: .......................................................................... 6 3.3.4 Task Prioritization Example ................................................................. 6

3.4 Data gathering methods .................................................................................. 7 3.5 Scenarios ........................................................................................................ 7

3.5.1 What to include in Scenarios ............................................................... 7 3.6 Task Analysis .................................................................................................. 8

3.6.1 Task Flow example .............................................................................. 9 4 Information Architecture ............................................................................................ 10

4.1 Primary Nouns ............................................................................................... 10 4.2 Primary Noun Views ...................................................................................... 10

4.2.1 Primary Noun example ...................................................................... 10 4.3 From Primary Nouns to Navigation ............................................................... 11 4.4 How do you organize a site? ......................................................................... 11 4.5 Different organization for different content .................................................... 11

5 General Navigation Rules ......................................................................................... 12 6 Main page’s function ................................................................................................. 12 7 Visual design ............................................................................................................. 12

7.1 Font size and Text ......................................................................................... 13 7.2 Color .............................................................................................................. 13 7.3 Download ...................................................................................................... 13 7.4 Content .......................................................................................................... 13

7.4.1 Scanability ......................................................................................... 13 7.4.2 Chunking ........................................................................................... 14 7.4.3 Sentence length ................................................................................. 14

8 Accessibility ............................................................................................................... 14 8.1 Older Adults and the Internet ........................................................................ 14

9 Suggested Navigation ............................................................................................... 14 9.1 Suggested Navigation Example .................................................................... 15

10 Revision History ........................................................................................................ 16 Appendix A - How to Develop User-Centered Web Sites ............................................... 17 Appendix B - 5 Things to Know About Users .................................................................. 19 Appendix C - Breadth vs. Depth ...................................................................................... 27 Appendix D - Fly-out Menus ............................................................................................ 29 Appendix E - Research-Derived Web Design Guidelines for Older People .................... 30



1 Introduction

The CommTech division at the Ohio State University College of Food, Agricultural, and Environmental Sciences (CFAES) develops a variety of websites for various departments within the College. The CommTech website development team has requested information from CGI regarding the basics of user centered design to assist them in better serving their customers. With the advance of the information age and an ever-increasing use of the Internet, User Centered Design (UCD) is a practice that itself has become an industry. A countless number of books, classes, lectures, and critics have emerged. This document does not intend to cover UCD in its entirety, but rather to summarize some principles and basics that appear to be most relevant to the types of websites CommTech is developing. The goals of this document and associated PowerPoint presentation are to: � Define User Centered Design; � Present some strategies for identifying and defining users; � Provide general navigation rules; � Provide tips on visual design, accessibility, and navigation; and � Include articles and websites as additional reference material.

2 What is User Centered Design?

User Centered Design is a philosophy that places the user at the center; it is a process that focuses on cognitive factors (such as perception, memory, learning, problem-solving, etc.) as they come into play during peoples' interactions with things. UCD seeks to answer questions about users and their tasks and goals, then use the findings to drive development and design. UCD seeks to answer questions such as:

• Who are the users of this 'thing'? • What are the users’ tasks and goals? • What are the users’ experience levels with this thing, and things like it? • What functions do the users need from this thing? • What information might the users need, and in what form do they need it? • How do users think this 'thing' should work? • How can the design of this ‘thing’ facilitate users' cognitive processes?



3 Getting to know your users

3.1 Design Strategy

A design strategy is a particular approach to developing a web site. Design strategies prevent feature creep. A design strategy helps you:

• Understand the stakeholder’s goals and expectations

• Gather background information

• Gather project requirements

• Understand branding and marketing goals The components of a design strategy include:

• Business goals (specific metrics regarding sales, costs, etc.)

• Target users

• General Tasks

• Technology Constraints

• Marketing/Branding Goals

• Critical Success factors (key outcomes that must be met to succeed) The following documents and groups are references for locating information to develop a design strategy.

• Project Requirements

• Standards

• Feedback from users

• Marketing

• Training/Help Desk

• Customer Service/Sales

• Human Resources (job descriptions)

• Business process or task flow diagrams

3.2 What information should I gather about users?

• Mental Models

• User profiles

• Work environment

• Scenarios of how user will use the interface (web site)

• Task analysis

• Goals

3.2.1 User’s mental model

• Guides all of their behavior

• Mental models come from past experience

• Mental models don’t always match reality

• Mental models set expectations, which drive and shape behavior

• 80% of usability derives from matching the conceptual model



3.3 The value of profiles and personas

A profile describes one user group. Personas are fictitious characters that are created to represent the different user types within a targeted demographic that might use your site or product. Personas are given characteristics and are assumed to be in particular environments based on known users' requirements so that these elements can be taken into consideration when creating scenarios for conceptualizing a site. The following information is used in developing a persona and scenarios:

• Demographic information

• Lifestyle choices

• Behavioral data

• User goals Personas can clarify assumptions about user and their tasks including their environment.

3.3.1 Profile Example:

Computer

Programmer

Retired Lawyer Buyer

Age/Gender Male, uppers 20s Males, 50s Female, 30s

Education Technical

education

Higher education Some college

education

Language English, Spanish English English

Computer / Web

Experience

High Low to Medium Low to Medium

Domain Experience Low to High Low to High Low to High

Task Knowledge Low to High Low to High Low to High

Expectation Ease of use, speed

of task

Ease of use, speed

of task

Ease of use, speed

of task

3.3.2 Persona example (includes environmental profile information):

The following is a persona for a fictitious home builder’s web site and for the Buyer profile above. Margaret is a buyer for XYZ Company. She is 38 years old and single. She makes an impressive salary and gets a good bonus every year. She drives a new Lexus. She wears designer clothing. She works with people who are very image conscious. She loves to name drop and tell people all the great places she goes on vacation. She is an avid golfer and wants to live on or near a golf course. She loves to have parties and cookouts to entertain her family, friends and co-workers. She wants everyone to be impressed with her house.



She has a laptop that she uses on business trips and a desktop computer in her home office. Lighting is good. Monitor size is 17 inches. She uses Internet Explorer to access the Internet. Goals:

• Live in an affluent neighborhood.

• Live on or near a golf course.

• Own beautiful and luxurious home. Questions:

• Can she live in a more prestigious community?

• Where does everyone else want to live?

• Can she get the best upgrades on products?

• Are they are specials or promotions going on now?

• What is the most stylish home?

• What is the most popular model?

3.3.3 Task Profile Example:

Following a profile and persona definition, a task provide is completed to identify tasks to further analyze and redesign by the types of user groups.

Task

Roles

Computer

Programmer

Retired

Lawyer Buyer

View benefits of new build over existing X

View Home building process X X

View home locations X X X

View school information per location X

View park/club/mall information per location X X X

View Models X X

View warranty X

Use mortgage calculator X

View Product upgrade information X

View promotion info X

View competitive info X

View company info X

View home building progress X

3.3.4 Task Prioritization Example

The task matrix shows the importance and frequency of scenarios for a particular user persona.



3.4 Data gathering methods

The following are various methods for gathering information on the website users.

• One-on-one interviews (can be combined with user observation)

• User observation (can be combined with one-on-one interviews)

• Combined method

• Focus groups

• JAD Sessions

• User group meetings

• Surveys

• Help desk and support lines

• Web analytic analysis

3.5 Scenarios

A scenario is a concrete description of activity that the user engages in when performing a task, a description sufficiently detailed so that design implications can be inferred and reasoned about. (J.M. Carroll, 1995) Scenarios focus on what the persona wants to do, why they want to do it, and what they expect from using your web site. A persona will have one to five scenarios.

3.5.1 What to include in Scenarios

• Range of functions

• Range of tasks

• Frequently-performed tasks

• Things the users most want to do

Importance High Low

High

Frequency

Low

View home locations

View school, park, club info per location

View home building process

View promotion info View company info



• Mission-critical task with important consequences

• Complicated tasks Scenarios drive functions. Scenarios can be used in Use Cases.

3.6 Task Analysis

A task analysis helps define the following information. The outcome of a task analysis is a task flow.

• Describes individual tasks in great detail

• Covers the entire realm of functionality

• Documents paths and frequencies

• Identifies opportunities for improvement

• Has implications for navigation

• Provides the foundation for later screen design Tasks cover the entire range of user functionality. Scenarios cover a slice of the range of tasks. Task flow analysis can uncover too much looping, unnecessary steps or pages, helps predict errors, etc.



3.6.1 Task Flow example



4 Information Architecture

4.1 Primary Nouns

Primary nouns are things that users take action on or manipulate. There should be 1 to 3 “things” per task and primary nouns need to be obvious in web pages. Questions every web page should answer:

• Where am I?

• What is this page about?

• What can I do here?

• Where can I go?

4.2 Primary Noun Views

Primary Noun Views are different ways a primary noun can be presented. Each primary noun can have more than one view. For example, calendars can be presented in day, week or month. Emails can be presented in a list, detail, or thread view. Stock market data can be presented in summary, detail and graphical view. When primary nouns are clear, users know what they can take action on.

4.2.1 Primary Noun example

Task Flow:

1. Search for home locations � Option view location information

2. Search for home models in locations � Option view model upgrades � Option view product specials

3. Contact sale office to set up appointment

Alternate paths:

o Use mortgage calculator o View home building process

Primary Nouns Count Views Actions Attributes

Locations Hundreds List Detail

Search View

Name Area City State Price ranges Location



Primary Nouns Count Views Actions Attributes

Models Hundreds List Detail

Search View

Name location Price

Appointment Hundreds Detail New

Name Address Phone # Email Date Time

Home Building Calculator One Detail View Application

Home Building Process One Detail View Steps

Company One Detail View Text

Warranty One Detail View Text

4.3 From Primary Nouns to Navigation

• Review task flows and primary noun tables.

• Based on tasks, go through different scenarios with primary noun tables to determine views and actions of the primary noun that are necessary to accomplish tasks.

• In most cases, a view of a primary noun is a page.

• In most cases and action will take the user to a new page.

4.4 How do you organize a site?

• By topic

• By user

• By task

• By product/service

• By store/department

4.5 Different organization for different content

• Alphabetical

• Chronological

• Geographical

***Choose the scheme that best fits the user’s mental model***

A hybrid is a combination of more than one navigation system. Hybrid examples: Google News, 1800 Flowers



5 General Navigation Rules

• Most users expect the primary navigation to be on the top of left side of the page.

• Navigation should always be visible to allow quick navigation to the parts of the site.

• Provide context by using a visual cue to indicate to the user where they are in the site.

• Global navigation is a set of links that are always available to the user regardless of where they are in the site, like Search. They are usually located in the top right-hand portion of the page in the header section.

6 Main page’s function

• Defines site’s purpose.

• Provides a clear path to all the information on the site.

• Promotes critical and frequently used information that users are seeking.

• Emphasizes high priority tasks so that user has a clear starting point.

• Contains a search feature.

• Should not literally welcome the users to the site. Give them a concrete definition of what they can do on the site and starting point. A more appropriate use of “Welcome” is using it when the site recognizes a registered user.

7 Visual design

If a site is “busy,” it increases the user’s visual load making them work harder to find something. Visual design should be the user's ally:

• Use grids for preliminary page layout

• Create pages that are interesting, yet simple and uncluttered.

• Use graphics to: illustrate/inform (not decorate), increase the user’s satisfaction/motivation, aid navigation.

• Use graphics that are small (in file size) so they download quickly.

• Make the most important elements the most visually prominent.

• Treat text as a graphic element.

• Use color conservatively. Color can engage users, both emotionally and cognitively, but misapplication of color creates negative outcomes. (Try your design in monochrome first, then, one at a time, add a few colors.)

• Group like elements together.

• Use ‘white space’ to visually organize the page, to make important elements stand out, and to give users’ eyes some resting space.

• Maintain top-to-bottom, left-to-right flow for scanning view-only information. Use visual attributes to control focus. Scientific research indicates that the eye tends



to move from: Size- large to small, Shape- irregular to regular, Shade- dark to light, Color – saturated to desaturated. Use Visual hierarchy – the same area on every page for the same thing – logo, primary navigation, secondary navigation, etc. Use colors for those areas. (http://www.humanfactors.com/downloads/feb04.asp)

• Use contrast to control the user’s focus. Users look at the dark colors first.

• Group information by similarity, proximity, common region, alignment points. Use lines and colors to group information. White space helps group things. White space has the connotations of luxury, money, sophistication.

7.1 Font size and Text

• Size of font will depend on user. Older people prefer 12 point Arial or Verdana.

• Text links – Use 5 -7 words for text links. Link keywords only not the entire sentence. Links should be able to be understood out of context so avoid “Click Here” and “Read More”.

• Use blue for text links because that is what users expect. Keep all links underlined in case the user is color blind.

7.2 Color

• Use color sparingly.

• Make sure the type contrasts well with the background, and avoid the temptation to play with exotic color schemes.

• Use color as a grouping cue.

• Use color to show relationships.

• Use color to draw attention.

• Too much color creates “noise” making it difficult for the user to scan and interpret data.

7.3 Download

• Faster beats fancier.

• If visitors must wait a minute to download art, they'll leave your site and never come back.

7.4 Content

7.4.1 Scanability

• Users do not read, they scan the page

• Use short sentences

• Simple explanatory headings

• Lots of bullet points

• Consistent typefaces and layout

• Avoid too much color, too many caps and a wide range of typefaces



7.4.2 Chunking

• Use short "chunks" of information that can be located and scanned quickly

• Chunking can help organize and present information in a uniform format

7.4.3 Sentence length

• Use short, simple words

• Use active voice

• Use 5 -7 words per sentence

• Less is more

8 Accessibility

• Fly-outs menus cannot be read by screen readers because they are dependent on mouse interaction.

• Fly-out menus increase the motor and intellectual loads on the users. Older people have more problems with fly-out menus because they are unable to hit the target.

• All navigational elements should be available in HTML somewhere on the site so that readers for the disabled can interpret the site’s content.

• People with motor difficulties find it hard to hit the target accurately.

• Ensure sufficient color contrast for people with low vision and older people.

• Ensure the user can select items on the web page using the keyboard only.

• Links should be able to be understood out of context so avoid “Click Here” and “Read More”.

8.1 Older Adults and the Internet

• Technophobes

• Lower motor functions

• Harder to see/read Refer to Appendix E - Research-Derived Web Design Guidelines for Older People for Older People, for additional information.

9 Suggested Navigation

Instead of fly-out menus, use:

• Use a Hybrid Navigational Model with a persistent menu across the top for Primary navigation derived from categories (common short nouns, objects or general terms people use).

• For secondary navigation use a persistent list (like a Table of Contents) going down the left side of the page.



• Include a section of Quick Links in the right hand column for most used pages that otherwise could not be reached in one or two clicks. This can also be included in secondary navigation. It should be kept as short as possible. It should be placed prominently on the page so the user has easy access.

• Search should be located in the top right hand portion of the page in the header section.

9.1 Suggested Navigation Example

This site uses a persistent menu for primary navigation, persistent list for sub-level navigation and search.



10 Revision History

Version Date Author Section Description

Draft 1.0 March 5, 2007 Darcy Zur Muhlen All Original Document Creation



Appendix A - How to Develop User-Centered Web Sites

From User-Centered Design and Web Development (http://www.stcsig.org/usability/topics/articles/ucd%20_web_devel.html)

1. Involve users from the beginning

Guidelines can provide general information about users and user/web

interaction. However, that is not enough to make a particular site usable; it

is critical to discover how your particular users interact with this particular

site.

Involve users from the beginning by:

• Discovering their mental models and expectations

• Including them as an integral part of the design/development process

and team

• Observing them at their workplace; validating your assumptions about

them; analyzing their tasks, workflow, and goals

• Eliciting feedback via walk-throughs, card sorting, paper prototypes,

think-aloud sessions, etc.

2. Know your users

Ask questions such as the following and use the answers to guide

development and design decisions:

• How much experience do the users have

with: Computers? The Web? Domain

(subject matter)?

• What are the users’ working/web-surfing

environments?

• What hardware, software, and browsers do the users have?

• What are the users’ preferred learning styles?

• What language(s) do the users speak? How fluent are they?

• What cultural issues might there be?

• How much training (if any) will the users receive?

• What relevant knowledge/skills do the users already posses?

• What do the users need and expect from this web site?

3. Analyze user tasks and goals



Observe and interact with users (preferably at their workspace) as you

attempt to answer questions such as:

• What are the tasks users need to perform; how do they currently

perform these tasks? What is the workflow?

• Why do the users currently perform their tasks the way they do?

• What are the users’ information needs?

• How do users discover and correct errors?

• What are the users’ ultimate goals?

4. Don’t settle on a final direction too soon

Explore different designs and approaches and get user feedback before

making final direction, development, and design decisions.

5. Test for usability—repeatedly!

Usability testing is an iterative process; it is important to conduct usability

testing throughout the development cycle.

Usability testing can be conducted using elaborate labs and equipment or

using relatively simple and inexpensive means. But usability testing is the

only way you can know if this particular site meets these users’ needs.



Appendix B - 5 Things to Know About Users

By Jared M. Spool, Originally published: Dec 02, 2002 (http://www.uie.com/articles/five_things_to_know) "Know Your Users" is the mantra of any good designer. Yet, what should you actually know about your users? Over the years, we've studied the usability of hundreds of product and web site designs. We've seen designs that were incredibly effective for users and designs that fell tremendously short. One emerging pattern in our ongoing research is that design teams that know a lot about their users are more likely to produce user experiences that are usable, effective, and pleasing. In a recent usability test, we had the chance to observe a user, Leslie, visit Citibank's web site. Leslie had done business with the bank for years, through her existing checking, savings, and credit card accounts. It was the first bank account her parents set her up with and she'd been a loyal Citibank customer ever since. Leslie had recently come into a large sum of money, due to the unfortunate death of her ailing grandmother. Her grandmother was an important role model to Leslie. Leslie really wanted to take her inheritance and invest it for the future, just like her grandmother had done. However, she didn't know how to begin. Because of Leslie's loyalty to Citibank, who had always taken care of her money, she decided to turn to their web site for advice on investing. On the Citibank.com home page (figure 1), she was first tempted to go to the "Investing and Markets" link at the very top-center, but then the "Learn about a financial topic" pull-down caught her eye.



(Figure 1 - Citibank Homepage) Since she'd never really had enough money to invest before, she really was looking to learn about what all of her options were. She was thrilled that the pull-down contained an entry labeled 'Investing'. Before Leslie clicked on that entry, we asked her about what she thought the site would give her. She told us that she was looking for a good introduction to investing, outlining what all of her options were for putting this money away for the future. Leslie had all sorts of questions: Should she use the money to buy a house? Or invest in the market, since prices were so low? Or maybe she should do a little of both? Are there other ways to invest money that would work to better advantage? She was excited and anxious, feeling like a whole new world was opening up in front of her. Until she clicked. The site presented Leslie with a page that didn't contain any answers to her questions. Nor did any of the links seem to have anything to do with her issues. While the site promised that she would learn about investing, there was little she could learn from the content on this page.



(Figure 2 - Citibank Investing page) It wasn't that the page was blank. It contained all sorts of information. It just wasn't matching why Leslie had come to the site. With just two clicks, Leslie -- a life-long, dedicated Citibank customer -- decided to go elsewhere to invest her money. Leslie's experience is far too common. Citibank probably knows more about Leslie than any other institution on the planet. They know how old she is, where she was born, what languages she speaks, how much money she has, where she spends it, who her employer is, where she lives, what her hobbies are, and where she vacations. Yet, the design team didn't have the required information to make Leslie's experience a successful one. Was Leslie an outlier? Was she outside who Citibank was designing for? Possibly. We haven't talked with the team at Citibank, so we can't say for sure. It's very possible that they've decided to go after more experienced investors, leaving folks like Leslie to seek other sources, even if they have been life-long Citibank customers. That being said, Citibank.com does proclaim on the homepage that they are the 'one-stop solution for all your financial needs'. Sounds to us like they intend to help people just like Leslie with exactly these types of questions. Leslie large inheritance is a somewhat unusual circumstance. Is it really possible to design for her strange situation? Is it practical? Absolutely.



While it's rare that someone inherits a large amount of money without an investment plan, it's not unusual for people to start thinking about investing. Many sites have no trouble helping new investors. Fidelity.com (figure 3) and TDWaterhouse.com (figure 4) both have excellent retirement planners that would help Leslie (and many others like her) answer these questions. The Motley Fool (figure 5) provides a great 13-step intro, along with a getting started guide.

(Figure 3 - Fidelity Investing page)



(Figure 4 - TD Waterhouse Investing page)



(Figure 5 - Motley Fool Investing page) Even Citibank's competitor, Wells Fargo, will email Leslie an excellent tutorial on investing basics -- answering every one of her questions.



(Figure 6 - Wells Fargo Investing page) So, why did Citibank's design team fail to answer Leslie's questions with the site? It wasn't because they didn't know how to design a quality web site -- the site is very nicely put together. And it wasn't because these types of questions are hard to answer -- other sites do a more than adequate job. The problem is that team didn't know anything about Leslie. They needed to know why Leslie was coming to the site (her 'intentions'). They also needed to know that she'd just come upon a huge sum of money (her 'context'). The team also needed to know what Leslie knew about investing (her 'knowledge'), what she was capable of doing herself (her 'skills'), and the nature of the financial management she'd done in the past (her 'experience'). The user's intentions, context, knowledge, skills, and experience are the essential things that every designer needs to know. Without this, the team is going to design something that seems useful, but they'll never know if it actually helps the user. The result is exactly what we see with Citibank's design -- a lot of content, but not the right content. Unfortunately, these five things are beyond what normal market research can tell us. Market research can tell us age groups, income levels, geographic regions, even purchase behavior. But it can't tell us the key things we need to know.



Intentions are key, because they tell us what the user is trying to accomplish. They dictate the tasks on the site. A high school senior who is shopping around for the right college has different intentions than the student who is ready to apply for early admission. Both of these intentions dictate different design requirements. Context is also important. Someone who is faced with putting their first PowerPoint presentation together will interact with the application's features differently if the presentation slides are due in 3 weeks than if they need to ready for a board meeting this afternoon. For example, they'd be less likely to explore all of the application's chart customization capabilities when rushed and therefore need the defaults to be acceptable for important meetings. They wouldn't play with a how-to tutorial or try lots of ambiguous menu options, just to see what they do. Knowledge, skills, and experience are also critical. The user's knowledge dictates the terminology and concepts that they are familiar with. Someone with a medical background will know the difference between hypoglycemia and hyperglycemia. However, a parent of a newly diagnosed child with diabetes might confuse these two life threatening (and very different) conditions. Designers might choose terms like "Low Blood Sugar" and "High Blood Sugar" if they understand the user's existing knowledge. The user's skillset also dictates design decisions. When designing an intranet procurement process, the designers would create different screens for those materials procured by seasoned buyers, who have been doing purchasing for decades, than for the occasional employee who needs a new computer or office supply. Finally, the user's experience is a design factor. An experienced business traveler would know to avoid certain airports at certain times of the year, like Chicago's O'Hare in the winter, because of likely weather delays. A clever reservation system might recommend an alternate hub, such as Charlotte or Dallas, which doesn't run into the same problems. These five attributes are critical to quality experience design. So, how would the team at Citibank find out what they need to know? The problem can be broken into two pieces: information gathering and analysis. There are many techniques for information gathering, from informal interviews and discussions to more formal ethnographic techniques such as Contextual Inquiry, made famous by Karen Holtzblatt and Hugh Beyer of InContext Enterprises. For analysis, we're very fond of Persona development techniques, popularized by Alan Cooper, and of the mental model and gap analysis process practiced by the folks at Adaptive Path. Techniques like contextual inquiry, persona development, and mental model analysis can make or break a team's design efforts. Without these, much effort can go into the development of the user experience, only to have it fail for the user because the team failed to know what they needed.



Appendix C - Breadth vs. Depth

(http://www.humanfactors.com/downloads/apr03.asp) Research comparing navigation efficiency through sites of varying depths and breadths broadly converges on the findings that users find roughly 16 (ungrouped) top-level links leading into 2-3 subsequent menus the most efficient, learnable and least error prone. This knowledge is well and good, but what does that really mean for designers? Today? Now? First, we can derive some broad (and largely intuitive) design guidelines from this work: Too deep is too deep: users have a more difficult time encoding, and consequently navigating, deep sites. Too broad is too broad: conversely extremely broad sites (which may encourage satisficing) also present a challenge to efficient navigation. Effective sub-grouping reduces perceived breadth: grouping navigation elements thematically improves performance for even the broadest structures. Clear labels improve navigation accuracy: creating clear and distinct labels for navigation elements enhances performance. More interestingly, careful consideration of the specific tasks used in these studies suggest that the breadth/depth findings map directly to effective Intranet design. Consider the typical participant's task in these studies: find an explicitly named target (search navigation) or navigate to an implicit, user-selected token within a specified category (browse navigation). Since Internet users frequently come to the Web looking for information about a concept, but without a specific page in mind, it is commendable that researchers have begun to focus more extensively on browse-driven exploration. However, it also must be noted that both implicit and explicit search tasks are still essentially serial tasks. That is, the research participants in these studies completed well-defined, single tasks, returning to the home page before initiating the subsequent task. This approach maps directly to the serial task completion behavior patterns observed for the frequently executed Intranet tasks: find a phone number; download a form; check the stock price; change personal benefits information, find a policy. Thus, the breadth/depth research speaks directly to optimal structure for Intranet design. Further, the cumulative findings of the research challenges the widely implemented approach that Intranets should focus corporate or institutional news wrapped in what is typically a tab-based (or tab plus left side navigation) functional navigation design. Instead, this research suggests that moderately broad site structures, consisting essentially of functionally grouped, transparently labeled link lists will provide the most effective navigation structure with the best perceived usability on Intranets. Anecdotal user-centered field analysis and prototype validation provides additional support for this approach to Intranet design. Designers who want to know how to take advantage of the depth/breadth research need to think about the kinds of tasks that people do on their sites, and how people approach doing those tasks. Do users tend to do one task at a time? Do they finish that task



before they start another? (Intranets are one example of a site type where this serial task completion model holds.) If so, then the task approach on your site is parallel to the task flow that was tested in the depth/breadth work. Therefore, these results apply and a broad, shallow menu architecture should provide users the most efficient and learnable access to resources on your site. In this case, however, the specific type of site is less important. In applying these results it is more important to think about what people do, and how they do it on your site.



Appendix D - Fly-out Menus

“The biggest problem with fly-out menus is that they aren’t usually implemented well and are used with full understanding of how they might affect the user. In general they cause problems and seem, to me anyway, to cause more harm that good.” (Usability and Fly-Out Menus http://www.7nights.com/asterisk/archive/2004/03/usability-and-flyout-menus) “Sites without these design (fly-out menus) elements did a better job of getting users to the content they sought and to valuable content they didn't previously know existed.” (Users Decide First; Move Second

http://www.uie.com/articles/users_decide_first/) “We found users follow a pattern: they decide what they are going to click on before they move the mouse.” “Unfortunately the information in fly outs, rollovers, or dropdowns can't help users decide where to click because the information isn't available to users when they are making their decision. It isn't until after they've decided where to click that they see what the element has to say.” In our studies, we observed that once users realized there was more information available to them, they stopped and re-evaluated the screen. Users seemed disoriented by this disruption in activity and they lost confidence that they were clicking in the right places. The users now questioned a choice that seemed to be a good one earlier. Some dropdown and fly out implementations required our users to use awkward

movements to make simple choices.”

Using Fly-out menus These menus increase the motor and intellectual loads on the users. Older people have more problems with fly-out menus because they are unable to hit the target. “They had already guessed it would be under About Verizon and were ready to click on it. However, when they moved their mouse over that icon, more options appeared. They saw the Verizon Foundation link appear, but every time they went to click on it, the link would disappear. Instead of using a natural movement of bringing the cursor straight across, the rollover forced the user to use an awkward two-step movement: move down then to the left.” (Users Decide First; Move Second

http://www.uie.com/articles/users_decide_first/) “MSNBC.com has a similar problem with the fly out menus they've designed for their news. Users became frustrated because they couldn't see the content in advance of choosing a category and some had problems with the menus going away when they used natural movements. Users expended so much effort to select a menu choice that they often missed stories that might otherwise have attracted their attention.”



Appendix E - Research-Derived Web Design Guidelines for Older People