Usability 1 of 58

User-Centered Design (UCD).........................................................................................................................6What is UCD?...............................................................................................................................................6Components of UCD....................................................................................................................................6Design Stages:.............................................................................................................................................6

What is Usability?...........................................................................................................................................7What makes a website or piece of software usable?...................................................................................7Why is Usability Important?..........................................................................................................................7How Do You Achieve a High Level of Usability?..........................................................................................8Where is Usability Applied?.........................................................................................................................8

Methods........................................................................................................................................................... 8Methods - Methods Section Overview..........................................................................................................8Cognitive Walkthrough...................................................................................................................................9

What is it?..................................................................................................................................................... 9How do I do it?.............................................................................................................................................9When should I use this technique?..............................................................................................................9

GOMS............................................................................................................................................................... 9GOMS Models: An Approach to Rapid Usability Evaluation........................................................................9

Usability Inspection......................................................................................................................................10Formal Usability Inspections.......................................................................................................................11

What is it?................................................................................................................................................... 11How do I do it?...........................................................................................................................................11When should I use this technique?............................................................................................................12

Planning......................................................................................................................................................... 12Why Are You Developing a Web Site?......................................................................................................12Who Should Come to Your Site?...............................................................................................................12Decide on your target audiences...............................................................................................................12When and Why Will They Come?..............................................................................................................13

Analyze context of use & Content Quality..................................................................................................13Benefits......................................................................................................................................................13Method - Planning......................................................................................................................................13This may include:.......................................................................................................................................13Before the meeting.....................................................................................................................................13At the meeting............................................................................................................................................13After the meeting........................................................................................................................................14Relevance..................................................................................................................................................14Overall checklist.........................................................................................................................................14How to improve relevance..........................................................................................................................14Overall checklist.........................................................................................................................................14When to use animation..............................................................................................................................14How to improve content depth and breadth...............................................................................................14Overall checklist.........................................................................................................................................15How to improve site timeliness...................................................................................................................15Goals.......................................................................................................................................................... 15Overall checklist.........................................................................................................................................15How to help people achieve their information goals...................................................................................15Structure.....................................................................................................................................................15Overall checklist.........................................................................................................................................15

COMPETITOR ANALYSIS.............................................................................................................................16Marketing Plan Components: Competitor & Issues Analysis.....................................................................16Benefits of Preparing a Competitor and Issues Analysis...........................................................................16COMPETITOR ANALYSIS.........................................................................................................................17

Requirement - Early usability tests.............................................................................................................17Characteristics...........................................................................................................................................17Early usability tests....................................................................................................................................17

Requirement - User Surveys........................................................................................................................18Surveying user opinions of ease of use.....................................................................................................18Different Surveys........................................................................................................................................18

Requirement - Contextual Inquiry...............................................................................................................18Characteristics...........................................................................................................................................18Contextual Inquiry, What is it?...................................................................................................................19How do I do it?...........................................................................................................................................19

Usability 2 of 58

When should I use this technique?............................................................................................................20Requirement - User Observation.................................................................................................................20

Summary.................................................................................................................................................... 20Benefits......................................................................................................................................................20Planning.....................................................................................................................................................20Running......................................................................................................................................................20Reporting....................................................................................................................................................21Guidelines for User Observation................................................................................................................21

Requirement - 10 STEPS - User Observation.............................................................................................22Requirement - Online Surveys.....................................................................................................................23

Characteristics...........................................................................................................................................23Some hints for effective online surveys:.....................................................................................................24

Requirement - Focus Groups......................................................................................................................24Focus groups.............................................................................................................................................24Focus groups.............................................................................................................................................25What is a focus group?..............................................................................................................................25What do you get from a focus group?........................................................................................................25What do you not get from a typical focus group?.......................................................................................25This document contains the following sections:.........................................................................................25Preparing for Session.................................................................................................................................26Developing Questions................................................................................................................................26Planning the Session.................................................................................................................................26Facilitating the Session..............................................................................................................................26Immediately After Session.........................................................................................................................27

Requirement – Individual Interviews...........................................................................................................27Individual interviews...................................................................................................................................27Individual interviews...................................................................................................................................27What do we mean by individual interviews?..............................................................................................27Why conduct individual interviews?...........................................................................................................27When should you conduct individual interviews?.......................................................................................27Individual interviews and focus groups: What's the difference?.................................................................27What makes an interview successful?.......................................................................................................28Steps in Conducting Interviews..................................................................................................................28

Requirement – Brainstorming.....................................................................................................................29What is Brainstorming?..............................................................................................................................29Benefits......................................................................................................................................................29Planning.....................................................................................................................................................29Nurturant phase.........................................................................................................................................29Step by Step...............................................................................................................................................29The Process Overview...............................................................................................................................30

Requirement – Evaluating Existing Systems.............................................................................................32Benefits......................................................................................................................................................32Method – Planning.....................................................................................................................................32Before the meeting.....................................................................................................................................33At the meeting............................................................................................................................................33After the meeting........................................................................................................................................33Output........................................................................................................................................................ 33

Requirement – Card Sorting........................................................................................................................33Card sorting –Charastrics..........................................................................................................................33Card sorting................................................................................................................................................33What is card sorting?.................................................................................................................................33What happens in a card sorting session?..................................................................................................33Why use index cards with one topic per card?...........................................................................................34How Does Card Sorting Work?..................................................................................................................34Getting the cards ready..............................................................................................................................34Arranging for card sorting sessions............................................................................................................34Conducting a card-sorting session.............................................................................................................34Analyzing data............................................................................................................................................35

Requirement – Scenarios of use.................................................................................................................35Scenarios of use (Use cases) Summary....................................................................................................35Benefits......................................................................................................................................................35Method....................................................................................................................................................... 35

Usability 3 of 58

Practical guidelines....................................................................................................................................35More information........................................................................................................................................36Next steps..................................................................................................................................................36Requirements meeting Summary...............................................................................................................36Benefits......................................................................................................................................................36Method 1. Quality in use requirements......................................................................................................362. Detailed usability requirements..............................................................................................................36

Requirement – Task Analysis......................................................................................................................37Summary.................................................................................................................................................... 37Benefits......................................................................................................................................................37Method - Task decomposition....................................................................................................................37

Requirement – Requirements Meeting.......................................................................................................38Summary.................................................................................................................................................... 38Benefits......................................................................................................................................................38Method....................................................................................................................................................... 38Arrange a workshop attended by:..............................................................................................................38For each chosen task and user type estimate:..........................................................................................38

Prototype - Design Guidelines.....................................................................................................................38Summary.................................................................................................................................................... 38Benefits......................................................................................................................................................39Contents.....................................................................................................................................................39Graphic Design..........................................................................................................................................39Navigation..................................................................................................................................................39Functions....................................................................................................................................................39

Prototype - Paper Prototyping.....................................................................................................................40Introductory articles....................................................................................................................................40Purpose......................................................................................................................................................40Benefits......................................................................................................................................................40Four stages of paper prototyping may be required:...................................................................................40Concept design..........................................................................................................................................41Interaction design.......................................................................................................................................41Screen design............................................................................................................................................41Screen testing............................................................................................................................................41How Good Does Your Web Site Look on Paper?......................................................................................41Navigation/Flow..........................................................................................................................................41Content.......................................................................................................................................................41Layout........................................................................................................................................................ 41Functionality/Interactivity............................................................................................................................42Summary description.................................................................................................................................42Typical Application Areas...........................................................................................................................42Benefits......................................................................................................................................................42Limitations..................................................................................................................................................42Cost of use.................................................................................................................................................42Detailed description of method...................................................................................................................43Sketching...................................................................................................................................................43User testing................................................................................................................................................44

Prototype - Heuristic Evaluation.................................................................................................................44What is Heuristic Evaluation?....................................................................................................................44How can I Use Heuristic Evaluation on my Site?.......................................................................................44Choose your Evaluators.............................................................................................................................45Heuristic Evaluation - a Step By Step Guide..............................................................................................45

Prototype - Parallel Design..........................................................................................................................48Summary.................................................................................................................................................... 48Benefits......................................................................................................................................................48Method....................................................................................................................................................... 48Evaluate prototype.....................................................................................................................................49

Prototype - Evaluate Prototype...................................................................................................................49Purpose......................................................................................................................................................49Benefits......................................................................................................................................................49Method....................................................................................................................................................... 50Reporting....................................................................................................................................................50

Usability Testing - Dignostic Evaluation....................................................................................................50

Usability 4 of 58

Summary.................................................................................................................................................... 50Benefits......................................................................................................................................................50Method Planning........................................................................................................................................50Running sessions.......................................................................................................................................50Output........................................................................................................................................................ 51

Usability Testing - Performance Testing....................................................................................................51Performance testing Summary...................................................................................................................51Benefits......................................................................................................................................................51Method Planning........................................................................................................................................51Running sessions.......................................................................................................................................51Output........................................................................................................................................................ 51

Usability Testing - Heuristic Evaluation.....................................................................................................52Benefits......................................................................................................................................................52Method....................................................................................................................................................... 52Planning.....................................................................................................................................................52Running......................................................................................................................................................52Reporting....................................................................................................................................................53

Usability Testing - Critical Incident Technique..........................................................................................53Critical Incident Technique Analysis Summary..........................................................................................53Benefits......................................................................................................................................................53Method....................................................................................................................................................... 53What do you test........................................................................................................................................53How do you test it.......................................................................................................................................53Analysis and Reporting..............................................................................................................................54

UI Specifications...........................................................................................................................................541 Purpose of the Document.......................................................................................................................542 UI Design Introduction.............................................................................................................................542.1 Consistency..........................................................................................................................................552.2 Accessibility (A11Y).............................................................................................................................553 Developing the UI....................................................................................................................................553.1 Top Level Panel...................................................................................................................................553.2 Component Hierarchy..........................................................................................................................553.3 Proper Components.............................................................................................................................56NetBeans Components..............................................................................................................................56Wrapped label............................................................................................................................................563.4 Layout..................................................................................................................................................56Resizing.....................................................................................................................................................563.5 Component Visual Properties..............................................................................................................563.6 Texts....................................................................................................................................................563.7 Keyboard navigation............................................................................................................................57Tab traversal..............................................................................................................................................57Mnemonics.................................................................................................................................................573.8 Accessibility..........................................................................................................................................573.9 Windows and Dialogs...........................................................................................................................58

Use Cases......................................................................................................................................................58

Usability 5 of 58

User-Centered Design (UCD)We employ User-Centered Design (UCD) techniques to evaluate technology products. The ultimate goals of UCD are to develop easy-to-use products that lead to increased user satisfaction and meet your organizational or business objectives. The Center focuses primarily on analysis of user requirements, conceptual design of technology products, and usability evaluation.

What is UCD?

UCD is a philosophy that places the user at the center of the design and development process right from the very beginning when the product is still in the conception phase and checking at every step of the way with potential users to be sure they will be comfortable with the final design.

NOTE: Although UCD is the ideal process for product development, it presupposes that you employ it right from the very beginning. If you have already begun development or are at the final stages, doing some product evaluation is better than doing none and it will yield very useful user feedback, which you can incorporate into the product design before launch.

Components of UCD

Usability and accessibility product evaluation are two critical components of the user-centered design (UCD) process.

Usability - Measures the effectiveness, efficiency, and satisfaction with which users achieve specified goals:

Effectiveness - Can users complete tasks, achieve goals with the product, do what they want to do?

Efficiency - How much effort and time do users require to achieve their goals? Satisfaction - What do users think about the product's ease of use?

Accessibility - Enhances Web sites, Web applications, software, and other products to ensure that they are understandable and navigable for users of all abilities.

Design Stages:

User Requirements Analysis o Work with product team to decide on product goals from the perspective of the user and

the organization/business o Determine the user needs and target usability requirements

Usability 6 of 58

o Conduct expert evaluation (heuristic evaluation) of existing product user interface o Perform a Web accessibility compliance evaluation o Perform a competitive analysis o Perform user interviews and surveys

Conceptual Design, Prototypes, and Evaluation o Work with the design and development team to sketch out a high-level product design o Rapidly create visual representations (mockups) or interactive representations

(Prototypes) of the product. o Evaluate usability through focus groups, front-end concept evaluation, and walkthroughs o Repeat this process (design iteration) until the design and usability goals are met

Design and Implementation o Work with the design and development team to revise user interface based on concept

evaluation o Create the user interface using standards-compliant code o Design for accessibility

NOTE: Since development is not the primary focus of the UAC, we work with the department of Communication and Information Technologies within the Office of University Outreach and Engagement and other organizations to coordinate and support the work in this stage.

Usability Evaluation o Conduct the user experience evaluation on the final design o Conduct an accessibility compliance evaluation based on Section 508 standards and Web

Content Accessibility Guidelines (for Web sites and Web applications) o Work with the design and development team to improve the product based on evaluation

results o Repeat this process (production iteration) until the organizational/business goals are met

Launch and Maintenance o Document everything o Continue to collect feedback from users/customers to improve the product in future

releases

What is Usability?Usability addresses the relationship between tools and their users. In order for a tool to be effective, it must allow intended users to accomplish their tasks in the best way possible. The same principle applies to computers, websites, and other software. In order for these systems to work, their users must be able to employ them effectively.

What makes a website or piece of software usable?

Usability depends on a number of factors including how well the functionality fits user needs, how well the flow through the application fits user tasks, and how well the response of the application fits user expectations. We can learn to be better user interface designers by learning design principles and design guidelines. But even the most insightful designer can only create a highly usable system through a process that involves getting information from people who actually use the system. Usability is the quality of a system that makes it easy to learn, easy to use, easy to remember, error tolerant, and subjectively pleasing.

Why is Usability Important?

From the user's perspective usability is important because it can make the difference between performing a task accurately and completely or not, and enjoying the process or being frustrated. From the developer's perspective usability is important because it can mean the difference between the success or failure of a system. From a management point of view, software with poor usability can reduce the productivity of the workforce to a level of performance worse than without the system. In all cases, lack of usability can cost time and effort, and can greatly determine the success or failure of a system. Given a choice, people will tend to buy systems that are more user-friendly.

Usability 7 of 58

How Do You Achieve a High Level of Usability?

The key principle for maximizing usability is to employ iterative design, which progressively refines the design through evaluation from the early stages of design. The evaluation steps enable the designers and developers to incorporate user and client feedback until the system reaches an acceptable level of usability.

The preferred method for ensuring usability is to test actual users on a working system. Achieving a high level of usability requires focusing design efforts on the intended end-user of the system. There are many ways to determine who the primary users are, how they work, and what tasks they must accomplish. However, clients' schedules and budgets can sometimes prevent this ideal approach. Some alternative methods include user testing on system prototypes, a usability inspection conducted by experts, and cognitive modeling.

Where is Usability Applied?

Usability is one of the focuses of the field of Human-Computer Interaction. As the name suggests, usability has to do with bridging the gap between people and machines. A user interface (or human-computer interface) refers to the parts of a hardware and/or software system that allow a person to communicate with it. This includes output devices (the way the computer talks to a user) and input devices (the way a user talks to the computer). Typical "output devices" include computer monitors and the windowing systems that run on them, but also include speakers and other devices that provide feedback. "Input devices" include peripherals like keyboards, mice, and joysticks, but also include microphones and even eye movement devices. Each of these interface components has devices corresponding to the visual (sight), aural (sound), and haptic (touch) channels of the brain. Usability engineering studies these elements of the user's experience.

MethodsThere are a variety of approaches to usability evaluation that you may choose to take. The methodologies can be divided into two broad categories: those that gather data from actual users and those that can be applied without actual users present.

Your choice of method depends on: Cost of evaluation Appropriateness to project Time constraints Cost of implementation Cost of training new users

Usability evaluations can be conducted at many stages during and after the design and development process. In choosing a method, it is important to calculate the cost not only in terms of time and materials involved, but also in terms of the impact on the end-users, especially considering the cost of losing return visitors to your website due to unusable design.

Methods - Methods Section OverviewCognitive Walkthrough is an approach to evaluating an interface based on breaking down and analyzing actions that a user must perform in order to use the system or perform a task.

Focus Groups gather groups of users to get their feedback, initial reactions to a design, and discuss their preferences. Focus groups can be useful for raising issues that may not come out during interviews.

GOMS is a family of techniques for modeling and describing human task performance. GOMS is an acronym that stands for Goals, Operators, Methods, and Selection Rules.

Prototyping involves developing representations of a system for testing purposes and can range from simple sketches to almost fully functional systems.

Usability 8 of 58

Task Analysis evaluates how the end-user actually uses software or websites. An analyst determines the user goals and tasks, and then makes recommendations aimed at increasing efficiency and user-friendliness.

Usability Inspection reviews a system based on a set of usability guidelines. Experts familiar with issues of usability in design perform the usability inspection.

User Testing observes actual users interacting with software or websites. Users are asked to perform tasks while usability experts observe and take note of their actions

Cognitive Walkthrough 

What is it?

Cognitive walkthrough is a review technique where expert evaluators construct task scenarios from a specification or early prototype and then role play the part of a user working with that interface--"walking through" the interface. They act as if the interface was actually built and they (in the role of a typical user) was working through the tasks. Each step the user would take is scrutinized: impasses where the interface blocks the "user" from completing the task indicate that the interface is missing something. Convoluted, circuitous paths through function sequences indicate that the interface needs a new function that simplifies the task and collapses the function sequence.

How do I do it?

Begin by evaluating a system specification in terms of the tasks users will perform with that system. It helps to identify the user's goals and purpose for each task. For example, the interface for operating a car begins with the goals of opening the door, sitting down in the driver's seat with the controls easily accessible, and starting the car. And we're not even driving yet! This example shows the granularity that some walkthroughs attain. The goal of "opening the door" could be broken down into sub-goals: find the key, orient the key, unlock the door, open the door. Each of these goals requires cognitive (thinking) and physical actions. To open the door, do I orient my hand with the palm up or with the palm down? What affordances are provided for opening the door? During the walkthrough, identify problems in attaining the goals. For example, some car doors accept keys only if they're oriented one way. Does this cause an unacceptable delay for the user? Since the sub-goal of opening the door is a prerequisite to operating the car, this might be a large issue.

When should I use this technique?

Cognitive walkthroughs are great for the early stages of development because they can be performed using just system specifications as a basis. Artists conceptions of what screens might look like can be used to give the walkthrough a more realistic bent.

GOMSGOMS is a family of techniques proposed by Card, Moran, and Newell (1983), for modeling and describing human task performance. GOMS is an acronym that stands for Goals, Operators, Methods, and Selection Rules, the components of which are used as the building blocks for a GOMS model. Goals represent the goals that a user is trying to accomplish, usually specified in a hierarchical manner. Operators are the set of atomic-level operations with which a user composes a solution to a goal. Methods represent sequences of operators, grouped together to accomplish a single goal. Selection Rules are used to decide which method to use for solving a goal when several are applicable.

GOMS Models: An Approach to Rapid Usability Evaluation

This project is a set of technology transfer activities concerned with moving the research results in human-computer interaction into practical methodologies for designing computer system interfaces that are in fact easy to learn and easy to use. The research results of interest are those from earlier and ongoing projects concerned with constructing and evaluating computational models of human cognition and performance in the context of humans interacting with systems.

Usability 9 of 58

The payoff of applying these models to interface design results from the limitations in the standard human factors methods for developing usable systems. These methods are effective, but are slow and costly to apply because they are based on empirical user testing: In a scientifically controlled setting, actual human users perform actual tasks using a prototype system; their performance is recorded and analyzed, along with any apparent problems and difficulties. The system design is then revised, and the system re-prototyped, and the test repeated, until overall system performance is adequate, no further problems are noted, or time and money has run out.

The goal of this work is to radically reduce the time and cost of designing usable systems through developing analytic engineering models for usability based on validated computational models of human cognition and performance. These models take a specification for a user interface design and a description of the user tasks that need to be carried out, and generate predictions of the time required to learn how to use the system, and the time required to carry out specific tasks. These predictions can be used instead of empirically collected data for much of the design process, thus saving considerable resources. The current models address the procedural quality of the interface -- the complexity, consistency, and speed of the procedures that the user must learn and execute in order to make use of the system. These models can help the design produce an interface that is reasonably usable, and then the slow and expensive empirical testing can be reserved for examining aspects of the interface not addressed by the models, and as a final check on the design.

The GOMS ModelEarlier research in HCI has resulted in a general concept, the GOMS model, which represents the procedural knowledge required to operate a system in terms of the user Goals, basic actions or Operators, Methods, which are sequences of operators that will accomplish goals, and Selection rules, which determine which method to apply to accomplish a goal. Research by Kieras and others has shown how this type of analysis can be used to obtain usefully accurate predictions of learning and execution time. This work was based on using a production-system representation of human procedural knowledge; GOMS models can be constructed using production systems, and so the empirical predictions can be generated from GOMS models.

We are involved a variety of activities to extend and apply this framework, and turn it into a teachable, standard methodology that can be applied in industry. An important first step was to encapsulate the earlier research on GOMS models into a task analysis method and model representation notation, called NGOMSL, that makes it easy to construct and apply a GOMS model. After learning this notation and techniques, software developers can calculate estimated learning and executing times, and identify man y qualitative problems in an interface design. Accumulating experience and research shows that such models are indeed practical and effective in interface design situations.

We are extending and refining the notation and modeling methodology to incorporate newer research results and make it even simpler and more useful. This notation, and the techniques associated with it, have been taught in university courses and short courses for industrial and professional groups.

Usability InspectionA usability inspection is a review of a system based on a set of guidelines. The review is conducted by a group of experts who are deeply familiar with the concepts of usability in design. The experts focus on a list of areas in design that have been shown to be troublesome for users.

Usability guidelines are usually derived from studies in human-computer interaction, ergonomics, graphic design, information design, and cognitive psychology. Some areas that get evaluated are the language used in the system, the amount of recall required of the user at each step in a process, and how the system provides feedback to the user. In particular, issues such as clarity, consistency, navigation, and error minimization are analyzed. Once the problems are discovered, the experts make recommendations for resolving these issues.

Usability 10 of 58

Formal Usability Inspections 

What is it?

Formal Usability Inspection takes the software inspection methodology and adapts it to usability evaluation. Software inspections, more commonly known as code inspections, started at IBM as a way to formalize the discovery and recording of software problems ("defects" in quality jargon, "bugs" in the vernacular). The technique also provided quantitative measurements that could be tracked using statistical process control methods. Code inspections were also adapted to check and track documentation defects, and usability defects were a logical next step.

Formal usability inspections include aspects of other inspection methods too. Heuristics are used to help non-usability professionals find usability defects. Inspectors walkthrough tasks with the user's goals and purpose in mind, similar to cognitive walkthroughs, although the emphasis is less on cognitive theory and more on encountering defects.

How do I do it?

This method formalizes the review of a specification or early prototype. The basic steps are to assemble a team of four to eight inspectors, assign each a special role in the context of the inspection, distribute the design documents to be inspected and instructions, have the inspectors go off on their own to do their inspection, and convene later in a formal inspection meeting. Defects found are assigned to responsible parties to be fixed, and the cycle continues.

Assemble the team. Pick a team of interested people, that is, people that have a stake in making the design more usable. This usually includes engineers from the design, quality assurance, documentation, training, and technical support groups. Each person brings a diverse viewpoint to look at the design, and the potential to discover usability defects is greater with a diverse team.

Assign roles. The formal usability inspection methodology borrows the inspection roles concept from code inspections. Each person on the team, besides having to inspect the design, has a role to play during the formal meeting. These roles are the following:

Moderator: Runs the meeting. Distributes and collects any materials needed. Schedules meetings, and coordinates defect assignment.

Owner: Designer of the product to be inspected. Usually the person to which defects are assigned. Fixes the defects.

Recorder (sometimes called Scribe): Logs defects during the formal meeting.

Inspectors: Everybody else. Inspects the design and reports any defects found. Everyone's an inspector regardless of their other role.

Distribute documents. For code inspections, this would be a code listing with line numbers plus instructions on what to look for--bad choice of syntax, variable problems, etc. For usability inspections, these include descriptions of the product, including screen mockups if any, user profiles, typical user tasks, heuristics to use, and a defect logging form.

Inspect the design. The inspectors work alone through the design and log the defects they find on the provided form. Having a form with an agreed-upon format for logging helps later during the formal meeting when the defects are discussed with the other inspectors. Each inspector assumes the role of a specific user from the user profile and walks through the tasks of a particular scenario. Prior to inspection, each inspector should review the heuristics and keep them in mind during their solo inspection sessions. Sometimes the form can be adapted to incorporate the heuristics as a checklist. Defects are logged according to the task the inspector was trying to execute and the location of the defect. With code inspections, the defect is located by line number--however, line numbers aren't usually present in interfaces. Defect location can be given as the screen and field or control name, or by the command and option attempted.

Usability 11 of 58

Hold the formal meeting. During the meeting, the moderator walks the team through each task/scenario as a group. Inspectors chime in at each step with the defects they found during their own inspection. Often, a lot of new defects are found as the inspectors discuss each defect--different aspects one inspector might not have thought of are brought up during the meeting. Everybody agrees on the recorder's logging of the defect--this formal log will be tracked later.

Inspectors might be tempted to think up solutions during the meeting, or the owner might take umbrage at the pronounced defects and protest each entry. These delays make the meeting run less smoothly and hurt the method's chance of success. Part of the mediator's role is to reduce these distractions so the defects can be agreggated and logged. There'll be plenty of time to fix them later.

Prioritize and fix the defects. Defects logged during the meeting are assigned to responsible persons to be fixed. The moderator often coordinates this effort, tracking fixed and open defects, and arranging solution-brainstorming meetings if necessary.

When should I use this technique?

Like other inspection methods, this technique is designed to reduce the time required to discover defects in a tight product design cycle. Since the inspectors can work with merely a specification or paper mockups, the technique lends itself well to early stages of development.

PlanningPlanning the Site Planning is critical because it helps you focus your objectives. It also helps you plan for usability activities that are part of the process of developing a successful site. Before you design, you must think about:

Why Are You Developing a Web Site?

I formation architects, designers, developers, and usability specialists should meet with project managers, content owners (subject matter specialists), and users to establish objectives for the site. What you want to achieve is a focused vision of what you — or your company or your agency — wish to do through the site.

Set measurable objectives. Think like a business. Develop measurable objectives. Ask questions like these:

How will I know (quantitatively) if the site is successful? · What will the consequences be if the site is not successful?

Who Should Come to Your Site?

A public Web site is available to everyone. But "everyone" is not necessarily the best definition of the audiences for your site. Think specifically about the people you want to attract to your site. You almost certainly have customers you want to target, probably several different groups of customers. List those groups.

Decide on your target audiences.

Sometimes it is useful to think of your target audiences by roles in relationship to the site. A classic division for e-commerce sites is "browsers" and "buyers." For another site, targeted audiences might be divided by type; for example:

Researchers outside the agency Researchers inside the agency Other staff in the division Non-research staff elsewhere in the agency .

For other situations, it may be useful to categorize audiences by profession, age, gender, or other characteristics.

Usability 12 of 58

The categories that are meaningful are ones that will lead you to think about what content to include and how to organize that content.

Keep user characteristics in mind while designing. You should also note several relevant characteristics of each audience to help you build a mental portrait of typical users in each group.

For example, relevant characteristics for researchers might be:

Busy Detail-oriented Knowledgeable about research and their subject matter May or may not be very experienced on the Web

Relevant characteristics for cancer patients and their families might be: anxious · highly motivated to get information · may not know medical terminology

Anxious Highly motivated to get information May not know medical terminology

When and Why Will They Come?

In the first planning question, "Why are you developing a Web site," you focused on your goals for the site — or your company's goals or the agency's goals. Users also have goals. Most users come to Web sites on what Jared Spool (an expert in the field of usability) calls "missions." They need something.

Analyze context of use & Content Quality

Benefits

Ensure that all factors that relate to use of the system are identified before design work starts. Provide a basis for designing later usability tests

Method - Planning

A good way to collect the information is to arrange a half-day meeting. Invite stakeholders who have knowledge about the intended users and usage.

This may include:

Project manager · User representative(s) · Developer(s) · Training Support

Before the meeting

When using a detailed checklist, to avoid prolonging the meeting it is important to fill in advance any items that are not contentious and highlight the issues that need to be discussed.

Provide all participants with a copy of the checklist.

At the meeting

Discuss and fill in each item on the context checklist. Try to obtain consensus where there is uncertainty or disagreement. If information is missing, agree how this can be obtained. Avoid prolonged discussion of minor issues.

After the meeting

Obtain any missing information. If the information is not easily available, arrange a field study to observe users in their work environment.

Usability 13 of 58

Circulate to all participants a summary of the conclusions, and the filled in checklist. Output description of the context of use, derived from the completed checklist.

Relevance

To be useful to an Internet audience, each site must deliver entertainment or knowledge, or improve the way its audience accomplishes some important task (such as purchase tickets or get fit). Designers sometimes take it for granted that their content is relevant. They also sometimes take it for granted that audiences will see or discover the relevance of their site.

Overall checklist

As you design and produce content for your site, use the following questions as a site review checklist:

Will the topic matter be interesting to the core audience? Will people have an opportunity to learn?

How to improve relevance

Make relevant, high-quality content your number one priority. Everything else is secondary, including look and feel, ease of use, uniqueness to the medium, and promotion.

Use market research to determine your target market and how valuable that market finds your site's primary content.

Tell potential audience members how your site is relevant to them. Identify related topics or tasks that are important to your target market.

Overall checklist

Will the graphics be appealing to the core audience? Will the audio be pleasing to the core audience? Does the music evoke the appropriate mood or emotion? Will the experience be enjoyable if a person views the site without audio?

When to use animation

Permanently moving (looping) animations should rarely be included on a Web page because they will make it very hard for your audience to concentrate on other page content. Research suggests that movement in our peripheral vision can dominate our attention. Research also indicates that moving text is harder to read than static text.

Use animation to draw the audience's attention to a single element out of several, or to alert people to updated information.

Use animation to indicate the function of a hot spot (for example, a moving hiker could indicate the current location of Mungo Park adventurers).

Use animation to draw attention to changes from one state to another (for example, animated map area changes could indicate deforestation over time).

Use animation to demonstrate navigation in a particular direction (for example, a simple page-flip animation could easily distinguish forward from backward movement).

Use animation to create icons for actions that can't be adequately expressed with a flat, static picture. In one experiment, such icons increased the comprehension of a set of abstract toolbar actions from 62 percent to 100 percent (Ronald Baecker, Ian Small, Richard Mander, "Bringing Icons to Life," in Proceedings of ACM CHI'91 Conference on Human Factors in Computing Systems, Use of Familiar Things in the Design of Interfaces, pp. 1-6, 1991).

How to improve content depth and breadth

Provide links to additional high-quality information in your articles or topics. Link people directly to relevant content (for example, the Cinemania article on Star Wars) rather

than the front page of an information resource (for example, the Cinemania home page). Add a consistent icon or motif to notify people when a link will take them off your site. Provide enough content breadth to appeal to a non-niche audience. Tailor search interfaces to the content domain. Present simple starting options. Prioritize and

format results for easy scanning. Use query reformulation techniques (that is, indicate related concepts, or offer to find "more like this") to refine the search.

Timely/Current Information

Usability 14 of 58

Obviously, timely information is more reliable and more interesting than stale information. Most sites do a poor job of communicating that their content is fresh and that they have a release schedule with specific exciting events.

Overall checklist

Will the site feature the latest information available on the topic? Does your site clearly tell people when and how often content is updated?

How to improve site timeliness

Use visual design cues to let people know that your information is timely. Include episode and article dates. Animation associated with dynamic content will reinforce its timeliness.

Tie content to current real-world events (such as movies, events, political elections, holidays, and so forth).

Highlight timely content on your site's home page. Don't count on people navigating to discover that you have fresh content.

Highlight fresh content in your promos to let people know you always have something new. Notify people to visit your site for exciting future events

Goals

When you started thinking about your site, you probably had a few killer ideas about what would hook people and make them want to return to your site. These high-priority features have to grab the viewer's attention as soon as they reach the site. By using design and written languages smartly, you can give your audience a set of goals that will lead them directly to your best content or help them experience your site in the way you'd like it to be experienced.

Overall checklist

Will the goal, subject matter, or point of the site be immediately clear? Is the value proposition (what's the relevance for me?) clearly conveyed? Will the basic steps to achieve the goal be clear from the start? Especially for games, will there be clear indications of progress toward the main goal? Is there any danger that the use of metaphors, language, graphics, or sounds set an inappropriate

expectation for the site?

How to help people achieve their information goals

Prioritize your content. Boldly promote your most exciting content with size, color, animation, and/or screen position.

Minimize less important content. Organize your home page/site by creating clearly distinguishable areas. Chunk information into

visual groups, based on topic or functional similarity from the audience's perspective (such as the navbar, the adventure area, and the ad area).

Use meaningful and consistent button names to label sections and content areas. Use distinguishing adjectives to label special versions of common Internet activities (for example, Kids Chat or News Chat).

Structure

A simple, clear structure and prominent in-site location feedback will enable your audience to easily navigate, greatly increasing your site's appeal. Icons, labels, metaphors, and other information may not be evident to the average person. Clarity on all levels is crucial.

Overall checklist

Will the design clearly communicate the site's core activities? Will the terms (especially the site's title and sections) adequately communicate the consequences of

selection or action? Will the core activities require few actions to locate? When appropriate, can each audience member control the pace of sequences (for example, skip or

replay sequences)? How to improve structure Most navigation pages should not scroll. However, a scrolling page should be used to contain a long

list of navigation links that form a conceptual unit (for example, NFL team links).

Usability 15 of 58

Try not to overload your pages with navigation choices. People will stop reading options after they see 4-5 distinct choices.

When people see a page, they immediately start trying to make sense of all their options. Grouping choices into functional units will reduce mental effort and help people quickly interpret your whole page. For example, with the appropriate layout people will quickly interpret a list of 12 adjectives (such as comedy, drama, western, and so on) as a single set of movie genres.

Content pages should contain one conceptual unit of content. In general, people prefer to scroll to continue a single unit of content like an article, skit, or short story, rather than click from page to page of an article. If people do need to click to continue an article, the word "continue" or a small right arrow () set into the context of the article have been effective. Don't visually separate article continuation buttons from the text body.

Avoid labeling buttons "Back," "Next," or "More." It's best to name the actual content (for example, "To page 2" or "To Bob Bejan cover story").

Provide context for links whenever possible (for example, "To Bejan video clip, download = 50 seconds).

Distinguish between decorative and functional graphic elements (links). Use 3-D, layout, rollovers, and cursor changes.

Group navigation elements in a common space that people can easily distinguish from content. This will avoid confusion and reduce the effort required for people to find what they need.

Place navigation elements or navbars in a consistent and/or predictable location. Provide a home base that is easy to locate. Break text in mid-sentence and/or use visual design cues to keep people reading past "visual cliffs" or

"below the fold" (for example, the bottom of a page). Never make the viewer scroll to locate important navigation buttons or the focal point of a page (such

as "Buy now"). Avoid page-load tricks that trap people in an endless loop when they try to use the back button to

leave some part of your site. Instructions and/or help should be presented in the context of completing tasks. Instructions and help

should be task-focused rather than feature-focused, and use common language rather than computer jargon.

Use multiple choice (for example, The capital of Illinois is a. Chicago or b. Springfield) to complete difficult tasks. Recognition is easier than recall (for example, The capital of Illinois is __?).

COMPETITOR ANALYSIS

Marketing Plan Components: Competitor & Issues Analysis

The purpose of the Competitor and Issues Analysis section of your marketing plan is to explain in detail the external challenges and opportunities your business may face.

Even though preparation of the analysis will take time, it will be worth it. You can benefit in a number of ways.

Benefits of Preparing a Competitor and Issues Analysis

You'll discover your company's competitive advantage–the reason customers do business with you instead of your competition. Then you'll be able to communicate your competitive advantage effectively to win potential customers.

Analyzing current issues and your competitors' offerings may spur ideas for innovative improvements to your product offerings.

You might find that there are some categories of customers whose needs are not being met. For example, if you plan to prepare and deliver gourmet meals, you may discover that a particular part of town is not currently being served. If you can satisfy unmet needs, you'll develop a market "niche."

By observing the actions of your competitors, you might learn more about your market. For example, does a successful competitor offer reduced prices during a particular season? If so, what might that tell you about your market's spending habits?

If you find that your market is saturated with capable competitors, you can avoid the costly mistake of starting a business without adequate demand. You can then redirect your efforts toward

Usability 16 of 58

something that will pay off instead. (For example, your research may tell you that there's an ample number of thriving gourmet meal services in your targeted market area already.)

COMPETITOR ANALYSIS

What to address in your competitor analysis

Names of competitors - At first glance, this may seem like an exercise in list-making. Obviously, if you sell ice cream by the cone, your competitors include other ice cream vendors. However, you're also competing with other dessert treats offered by grocery stores as well as other items competing for consumers' discretionary funds. So, list all of your competitors and include information on any that might enter the market during the next year.

Summary of each competitor's products - This summary should also include their location, quality, advertising, staff, distribution methods, promotional strategies, customer service, etc.

Competitors' strengths and weaknesses - It's important to see your competitors' strengths and weaknesses from your customer's viewpoint, not yours. List their strengths and weaknesses. State how you will capitalize on their weaknesses and meet the challenges represented by their strengths.

Competitors' strategies and objectives - This information might be easily obtained by getting a copy of their annual report. Probably, however, you will need to do some detective work or conduct an analysis of many information sources to understand competitors' strategies and objectives.

Strength of the market - Is the market for your product growing sufficiently so there are plenty of customers for all market players? Or, is the market so tight you are selling primarily to your competitors' customers? (If so, you need to have a strong competitive advantage.)

Requirement - Early usability tests

Characteristics

Users usually come to you You usually develop the scenarios Small numbers: one or two users at a time Total numbers: five to 12 users You observe and listen to actual behaviors May be formal or informal, quantitative and/or qualitative results Tester and user need not be at same location

Early usability tests

Consider starting your project with a usability test.

If you already have a Web site, you can find out 5/21/2007what works well for your users and what does not. If you do not yet have a site, use a competitor's site or one that has similar purposes.

You can learn a great deal that will help you build a new site — what to keep, what to expand on, what to change, how to avoid others' mistakes.

A usability test can be done quickly and inexpensively. What a usability test reveals about what users actually do is usually more valuable than what you learn in interviews and focus groups where you ask users about themselves and their work.

What users say they do and what they actually do are often different — because people aren't always aware of how they work. When talking about our work, we all skip steps because we do them automatically. We often cannot remember exactly how we do or did something. Watching and listening as users work is the most informative way to see what people do — and to get what you need to build a successful site.

Usability 17 of 58

Requirement - User Surveys

Surveying user opinions of ease of use

Do your users think your web site is easy to use? What aspects of your software need improving? Are users satisfied with your interface design? Find the answers - ask your users! For many organisations their Internet and/or intranet web services are a central part of their

business, but few have analysed what their users think about them. Software developers hear about user complaints - but are they representative? What sort of users

are dissatisfied, are they typical? A properly designed survey can answer these and other questions. ·

Designing and conducting your own survey is a laborious task with numerous pitfalls - an independent service can be the answer.

Usability Partners can provide a range of different standardised questionnaires for various types of product. Scientifically developed to produce valid and reliable results.

Different Surveys

Standard questionnaires Customized standard questionnaires Tailored surveys Multiple languages

Requirement - Contextual Inquiry

Characteristics

You go to the user's home or work site Users do their own work (different scenarios with different users) Small numbers: one or two users at a time Total numbers: five to 12 users You observe and listen to actual behaviors You see users' environments and the technology users have Usually informal dialogue with user, qualitative results Interviewer and user are physically at same location

Contextual inquiry

Contextual inquiry is basically a structured field interviewing method, based on a few core principles that differentiate this method from plain, journalistic interviewing. Contextual inquiry is more a discovery process than an evaluative process; more like learning than testing.

Site visits

Site visits are visits to customers with the goal of gathering data on the work practices of users. As soon as possible after the visit, the interview and observation data is collated into simple models of the working practices in interpretation sessions, and then consolidated into comprehensive models. The models form the foundation of the interaction design. This article covers the purpose and conduct of site visits.

Stalk your user

Design, ultimately, is problem solving. And the best way to discover which problems need solving is to look for them in context. Contextual inquiry is an increasingly popular method for discovering design information. Also known as ethnographic research or field studies, the idea is deceptively simple: Build useful products and watch your users as they work. The process itself sounds even easier: Go to where your users are and tag along with them.

What is contextual enquiry?

Usability 18 of 58

Contextual enquiry is a technique for examining and understanding users and their workplace, tasks, issues and preferences. It can be used to produce user needs analyses and task analyses, and feeds directly into design.

Contextual Inquiry, What is it?

Contextual inquiry is basically a structured field interviewing method, based on a few core principles that differentiate this method from plain, journalistic interviewing. Contextual inquiry is more a discovery process than an evaluative process; more like learning than testing.

Contextual inquiry is based on three core principles: that understanding the context in which a product is used (the work being performed) is essential for elegant design, that the user is a partner in the design process, and that the usability design process, including assessment methods like contextual inquiry and usability testing, must have a focus.

For example, suppose you need to assess the usability of a wrench for automotive repair. Using contextual inquiry, you'd visit mechanics at auto repair shops and see how they work. You'd take in not only physical arrangements such as the location of the tool chests, or cramped conditions inside engine compartments, but also environmental concerns, such as the level of cleanliness of their hands, or the noise level in the shop, or the tight schedules imposed by their bosses. All of these would help define a context for their work--and thus a context for the usage of your product, the wrench.

You'd also listen to their gripes about your product; how it slips out of their hands if they've been working on greasy stuff, how it gnaws the corners off stubborn bolts. You'd ask them what would make their jobs easier; what design changes would help them. They're a partner in the design process.

Of course, you'd conduct all this research centering on the one thing you're analyzing: the wrench. This focus is important--it sets the goals for the visit ("We need to know how they store their wrenches"). Once you're done with your site visit, you can assess from your notes whether you found out what you needed to know.

How do I do it?

Contextual inquiry follows many of the same process steps as field observations or interviews. Different considerations are kept in mind, however, with some portions of the process.

For example, interviewing during a contextual inquiry study usually does not include set, broadly worded questions. Instead, the partnership between the interviewer and interviewee is used to create a dialogue, one where the interviewer can not only determine the user's opinions and experiences, but also his or her motivations and context.

A lot of times, just having the interviewer around is going to make the interviewee a bit edgy. As the interviewer, you really need to be part of the user's world to be effective--sometimes, it takes a while before they're used to you hanging around. At that point, the job becomes much easier, since the users you interview will be more at ease with telling you what they really think about your product.

This usually means that this is a long-term study; you set up a relationship with the organization you're studying and agree on when you're going to visit, how often you'll be on site, and how long you'll be there each time. It's a lot like ethnographic studies where the ethnographer goes off to live in a particular culture for a year or two.

Figuring out who to interview is very important. Many times, the end user you're keeping in mind isn't the person that's going to be affected the most by your design or redesign. For example, when many corporate applications change or are upgraded, the person that is affected the most is the management information systems (MIS) person who has to go around and install the application on every computer in the building. Hanging around that person for a day will certainly give you an appreciation for ensuring that the installation process and interface is well designed.

Once you're done with the visit, assess whether you met your goals for the visit. Analyze your notes to determine questions for your next visit.

Usability 19 of 58

When should I use this technique?

Contextual inquiry is one of the best methods to use when you really need to understand the users' work context. Many times, the environment in which people work really influences how people use a product. It sounds like a cliche', but there really are people who print out their email and mark it up with comments before replying.

Also, this technique is great for finding out about work practices in domains that you know nothing about--whether it's lawyers looking up cases in a digital library, or roughnecks on an oil rig, or soldiers cooped up in a tank.

This technique is best used in the early stages of development, since a lot of the information you'll get is subjective--how people feel about their jobs, how work or information flows through the organization, etc.

Requirement - User Observation

Summary

Observational methods involve an investigator viewing users as they work in a field study, and taking notes on the activity that takes place. Observation may be either direct, where the investigator is actually present during the task, or indirect, where the task is viewed by some other means such as through use of a video recorder. The method is useful early in user requirements specification for obtaining qualitative data. It is also useful for studying currently executed tasks and processes.

Benefits

Allows the observer to view what users actually do in context. Direct observation allows the investigator to focus attention on specific areas of interest. Indirect observation captures activity that would otherwise have gone unrecorded or unnoticed.

It should be noted that observation can be obtrusive and subjects may alter their behaviour due to the presence of an observer. Co-operation of users is vital, so the interpersonal skills of the observer are important. Notes and videotapes need to be analysed by the note-taker, which can be time consuming and prevents the task being split up for analysis by a number of people.

Planning

Establish objectives and information requirements. Should the coverage be in breadth or in depth? It is extremely important to decide what will happen to the end-product of this process, and to tailor the whole process to the requirements of those who will receive the results.

Gain co-operation of contacts with the observation technique that you intend to carry out. Establish the times, places, and people who will be observed. Note that in some countries the law may prohibit you from taking video films of people without their explicit written consent.

Decide on the recording technique you will use. Will you rely on hand-written notes (traditional), audio, or video and audio records? Note that the more complete your record, the longer it takes to analyze. It is useful to be able to make some kind of first-cut analysis during observation.

Running

Make sure that those being observed are aware of the reason for your study and that they do not see you in negative terms. This is particularly important for mentally impaired and blind users who may be disturbed by a passive presence that they are not sure about.

Run a pilot observation session to get a feel for what to expect and to test out any observation sheets. This will also help to judge how long the observation session needs to be. If the session involves informal activities with the general public, they may wish to converse with the observer. Make sure that there is enough time for this.

Try to be as unobtrusive as possible. Do not let yourself or your equipment get in the way. Note down any events that you do not understand and try to clarify them with the user as soon as

the session is completed. Try to be aware of the range of influences that are affecting the user.

Usability 20 of 58

If possible photograph the users work area or the area of operation as this will act as a reminder of the environmental context.

After your observations, write down your first impressions before the analysis stage later on.

Reporting

Analyze, summaries, and report in relation to the objectives set out at the start.

Guidelines for User Observation

IntroductionUser testing covers a wide range of activities designed to obtain information on the interactions between users and computers. Most user testing requires considerable expertise in research methods, as well as skill in using complex data collection tools. For example, user-testing techniques include: interviews, focus groups, surveys, timed performance tests, keystroke protocols, and controlled laboratory experiments. Of the many user-testing techniques available, user observation is one technique that can be used by anyone with a concern for including the user in the product development process.

User observation involves watching and listening carefully to users as they work with a product. Although it is possible to collect far more elaborate data, observing users is a quick way to obtain an objective view of a product.

When to observe usersUser observation should be an integral part of the design process---from the initial concept to the product's release. Software design that includes user observation is an iterative process; user feedback provides the data for making design modifications. The iterative process assumes that preliminary human interface designs should exist prior to the development of underlying code. Interface designs should be tested frequently to determine which design should be implemented. Then, as the code develops, the entire product should be tested and revised several times.

Preparing for a user observation

Set an objective: Before you do any testing, you should take time to figure out what you're testing and what you're not. In other words, determine an objective for your test that focuses on a specific aspect of the product. By limiting the scope of the test, you're more likely to get information that helps you solve a specific problem.

Design the tasks: Your test participant will work through one or more specific tasks. These tasks should be real tasks that you expect most users will do when they use your product. The entire user observation should not run over an hour, so you should design tasks that focus on the part of the product you're studying. For example, if you want to know whether your menus are useful, you could design a task that requires the participant to access the menus frequently. After you determine which tasks to use, write them out as short, simple instructions.

Important: Your instructions must be clear and complete, but they should not explain how to do things you're trying to test. For example, if you want to find out whether users can navigate through your program easily, don't give them instructions for navigation. Or, if you want to know whether your interface is self-explanatory, don't describe how it works. This concept is extremely important to remember. If you teach your participants about something you're trying to test, your data will not be useful.

Decide upon the use of videotape: Although you can observe users effectively without using special recording equipment, you may want to use videotape to capture the entire session. By videotaping the session, you collect an enormous amount of valuable information that you can review and analyze after the test is over. If video equipment is not available, a tape recorder can be helpful for recording what is said during the test.

Determine the setting: The ideal setting for user observation is a quiet, enclosed room with a desk, the appropriate hardware and software, a video camera, and two microphones (one for you and one for the participant). Of course, you may not have all these things available when you need to observe; therefore, you should try to approximate the ideal setting as closely as you can. If you have to conduct the observation in a regular office, ask the people around you to keep the noise level down during the observation. The key is to make the environment as interruption-free as possible. Get the participants out of their offices, away from phone calls and people who might drop by.

Usability 21 of 58

Find representative users: When looking for participants, try to find people who have the same experience level as the typical user for your product. Don't ask people you work with regularly to be participants because they are probably familiar with your product or your opinions about the product. Generally, you should look for people who are familiar with the hardware you use but are not familiar with your product. You may want to ask pairs of people to work together on your tasks. You'll find that people working in pairs usually talk more than people working alone, and they also tend to discuss features of the product and explain things to each other.

Requirement - 10 STEPS - User Observation10 steps for conducting a user observationThe following instructions guide you through a simple user observation. Remember, this test is not designed as an experiment, so you will not get statistical results. You can, however, see where people have difficulty using your product, and you can use that information to improve it. These instructions are organized into steps. Under most of the steps, there is some explanatory text and a bulleted list. The bulleted list contains sample statements that you can read to the participant. (Feel free to modify the statements to suit your product and the situation.)

1. Introduce yourself.2. Describe the purpose of the observation (in general terms). Set the participant at ease by

stressing that you're trying to find problems in the product. For example, you could say:a. You're helping us by trying out this product in its early stages. b. We're looking for places where the product may be difficult to use.c. If you have trouble with some of the tasks, it's the product's fault, not yours. Don't feel bad;

that's exactly what we're looking for. d. If we can locate the trouble spots, then we can go back and improve the producte. Remember, we're testing the product, not you.

3. Tell the participant that it's okay to quit at any time. Never leave this step out. Make sure you inform participants that they can quit at any time if they find themselves becoming uncomfortable. Participants shouldn't feel like they're locked into completing tasks. Say something like this:

a. Although I don't know of any reason for this to happen, if you should become uncomfortable or find this test objectionable in any way, you are free to quit at any time.

4. Talk about the equipment in the room. Explain the purpose of each piece of equipment (hardware, software, video camera, microphones, etc.) and how it is used in the test.

5. Explain how to think aloud. Ask participants to think aloud during the observation, saying what comes to mind as they work. By listening to participants think and plan, you can examine their expectations for your product, as well as their intentions and their problem solving strategies. You'll find that listening to users as they work provides you with an enormous amount of useful information that you can get no other way. Unfortunately, most people feel awkward or self-conscious about thinking aloud. Explain why you want participants to think aloud, and demonstrate how to do it. For example, you could say:

a. We have found that we get a great deal of information from these informal tests if we ask people to think aloud as they work through the exercises.

b. It may be a bit awkward at first, but it's really very easy once you get used to it. c. All you do is speak your thoughts as you work. d. If you forget to think aloud, I'll remind you to keep talking. e. Would you like me to demonstrate?

6. Explain that you cannot provide help. It is very important that you allow participants to work with your product without any interference or extra help. This is the best way to see how people really interact with the product. For example, if you see a participant begin to have difficulty and you immediately provide an answer, you lose the most valuable information you can gain from user observations where users have trouble, and how they figure out what to do.

Of course, there may be situations where you have to step in and provide assistance, but you should decide what those situations might be before you begin testing. For example, you may decide that you can allow someone to flounder for at least 3 minutes before you provide assistance. Or, you may decide that there is a distinct set of problems with which you can provide help.

Usability 22 of 58

As a rule of thumb, try not to give your test participants any more information than the true users of your product will have. Following are some things you can say to the participant:

As you're working through the exercises, I won't be able to provide help or answer questions. This is because we want to create the most realistic situation possible.

Even though I won't be able to answer your questions, please ask them anyway. It's very important that I capture all your questions and comments on tape.

When you've finished all the exercises, I'll answer any questions you still have.

7. Describe the tasks and introduce the product. Explain what the participant should do and in what order. Give the participant written instructions for the tasks.

Important: If you need to demonstrate your product before the user observation begins, be sure you don't demonstrate something you're trying to test. (For example, if you want to know whether users can figure out how to use certain tools, don't show them how to use the tools before the test.)

8. Ask if there are any questions before you start; then begin the observation.

9. Conclude the observation. When the test is over: a. Explain what you were trying to find out during the test. b. Answer any remaining questions the participant may have. c. Discuss any interesting behaviors you would like the participant to explain.

10. Use the results. As you observe, you see users doing things you never expect them to do. When you see participants making mistakes, your first instinct may be to blame the mistakes on the participant's inexperience or lack of intelligence. This is the wrong focus. The purpose of observing users is to see what parts of your product might be difficult or ineffective. Therefore, if you see a participant struggling or making mistakes, you should attribute the difficulties to faulty product design, not to the participant.

To get the most out of your test results, review all your data carefully and thoroughly (notes, the video tape or cassette tape, the tasks, etc.).

Look for places where participants had trouble, and see if you can determine how your product could be changed to alleviate the problems.

Look for patterns in the participants' behavior that might tell you whether the product was understood correctly.

It's a good idea to keep a record of what you found during the test. That way, you have documentation to support your design decisions and you can see trends in users' behavior. After you've examined the results and summarized the important findings, fix the problems you found and test the product again. By testing your product more than once, you can see how your changes affect users' performance.

Requirement - Online Surveys

Characteristics

May have large number of responses Get users' self-report Good for wish lists, attitudes, experiences; not for actual behaviors Usually mostly closed questions (yes/no, multiple choice, short answer) May include open-ended questions, but they require more analysis Users may be located anywhere May be single-survey or iterative series

Usability 23 of 58

Some hints for effective online surveys:

Decide why you are surveying your users. At this early stage of Web site development, you probably want to learn more about who

they are, what experiences they have had with your site or similar sites, and what they want — that's all!

Decide where you will find the people you want to survey.

If you already have a site, post it there. Also consider other sites where users for your site might go and obtain permission to

announce your survey there. Consider getting permission to send broadcast email about the survey to lists of potential

users through professional societies, listservs, discussion groups, etc. Be sure to get permission from the list owners before broadcasting email.

Keep the survey short. Under 10 items is preferable.

Make the survey easy for users to do. It should take no more than five or10 minutes to complete.

Consider a mix of closed questions (multiple choice) and open-ended questions (users write down what they want to tell you).

Closed questions are easier to analyze. Open-ended questions may give you richer data and offer a glimpse at the terminology

your users use. Consider a mix of questions about demographics, users' prior experiences, and what

users want.

Consider using a series of surveys.

Gather information with a short survey that you make available where many people might see it and respond.

On the survey, ask if people are willing to answer more in-depth questions and ask those people to give you an email address.

Send follow-up electronic questionnaires to willing respondents who meet your criteria for the type of user you want to know more about.

Consider combining an online survey with individual interviews.

With an online survey, you reach many people in many places, but you don't get the depth of data that you get from individual interviews.

If you do individual interviews first, you get good ideas for survey questions and for the items on multiple-choice survey questions.

If you do individual interviews after gathering some survey data, you get to follow up with some people on issues and ideas that come from the survey answers.

Requirement - Focus Groups

Focus groups

Small group discussion Moderated by trained facilitator Usually everyone is in same location Self-report; good for attitudes, experiences, wish lists Not usually good for actual behaviors, but can combine with some aspects of behavioral usability

testing

Usability 24 of 58

Discussion influenced by group dynamics (for good or bad) Can be done as an electronic meeting, which allows for anonymity and reduces the effect of group

dynamics

Focus groups

What is a focus group? What do you get from a focus group? What do you not get from a typical focus group? \ What makes a focus group work well?

What is a focus group?

A focus group is a moderated discussion among eight to 12 users or potential users of your site. A typical focus group lasts about two hours and covers a range of topics that you decide on beforehand. Focus groups are a traditional market research technique, so marketing departments are often more familiar with focus groups than with usability testing or contextual interviews. However, the techniques produce different kinds of information. In a typical focus group, participants talk; you hear them tell you about their work. In a typical usability test or contextual interview, users act; you watch (and listen to) them doing their work.

What do you get from a focus group?

Users' attitudes, beliefs, desire Users' reactions to ideas or to prototypes

What do you not get from a typical focus group?

How users really work with Web sites What problems users really have with sites What makes a focus group work well? Select participants to represent the types of users you want to come to the Web site. (This is true of

all the data-gathering techniques.) Decide what you want to learn. (This is also true for the other data-gathering techniques.) Write a "script" for the moderator to follow. (In usability testing, you write scenarios — tasks — for

users to perform. In contextual interviewing, you let the context and the user's work shape the dialogue.)

Hire a skilled moderator to facilitate the discussion so that everyone participates and the group stays on track. (In the other techniques, you need skilled observers and listeners.)

Allow the moderator flexibility in using the script. The script usually gives the moderator questions to ask and topics to cover. The moderator may change the order of questions and topics to keep the discussion flowing smoothly. The moderator has to be a good judge of time to decide when to encourage more discussion on a topic and when to move on.

Tape the sessions and have one or more people take good notes. (This is also true of other data gathering techniques. Good notes are critical to making sense of what you see and hear in all these techniques.)

This document contains the following sections:

Preparing for Session Developing Questions Planning the Session Facilitating Session Immediately After Session Focus groups are a powerful means to evaluate services or test new ideas. Basically, focus groups

are interviews, but of 6-10 people at the same time in the same group. One can get a great deal of information during a focus group session.

Preparing for Session

Identify the major objective of the meeting. Carefully develop fix to six questions (see below). Plan your session (see below).

Usability 25 of 58

Call potential members to invite them to the meeting. Send them a follow-up invitation with a proposed agenda, session time and list of questions the group will discuss. Plan to provide a copy of the report from the session to each member and let them know you will do this.

About three days before the session, call each member to remind them to attend.

Developing Questions

Develop five to six questions - Session should last one to 1.5 hours -- in this time, one can ask at most five or six questions.

Always first ask yourself what problem or need will be addressed by the information gathered during the session, e.g., examine if a new service or idea will work, further understand how a program is failing, etc.

Focus groups are basically multiple interviews. Therefore, many of the same guidelines for conducting focus groups are similar to conducting interviews (see the Basics of Conducting Interviews).

Planning the Session

Scheduling - Plan meetings to be one to 1.5 hours long. Over lunch seems to be a very good time for other to find time to attend.

Setting and Refreshments - Hold sessions in a conference room, or other setting with adequate air flow and lighting. Configure chairs so that all members can see each other. Provide name tags for members, as well. Provide refreshments, especially box lunches if the session is held over lunch.

Ground Rules - It's critical that all members participate as much as possible, yet the session move along while generating useful information. Because the session is often a one-time occurrence, it's useful to have a few, short ground rules that sustain participation, yet do so with focus. Consider the following three ground rules: a) keep focused, b) maintain momentum and c) get closure on questions.

Agenda - Consider the following agenda: welcome, review of agenda, review of goal of the meeting, review of ground rules, introductions, questions and answers, wrap up.

Membership - Focus groups are usually conducted with 6-10 members who have some similar nature, e.g., similar age group, status in a program, etc. Select members who are likely to be participative and reflective. Attempt to select members who don't know each other.

Plan to record the session with either an audio or audio-video recorder. Don't count on your memory. If this isn't practical, involve a co-facilitator who is there to take notes.

Facilitating the Session

Major goal of facilitation is collecting useful information to meet goal of meeting. Introduce yourself and the co-facilitator, if used. Explain the means to record the session. Carry out the agenda - (See "agenda" above). Carefully word each question before that question is addressed by the group. Allow the group a few

minutes for each member to carefully record their answers. Then, facilitate discussion around the answers to each question, one at a time.

After each question is answered, carefully reflect back a summary of what you heard (the note taker may do this).

Ensure even participation. If one or two people are dominating the meeting, then call on others. Consider using a round- table approach, including going in one direction around the table, giving each person a minute to answer the question. If the domination persists, note it to the group and ask for ideas about how the participation can be increased.

Closing the session - Tell members that they will receive a copy of the report generated from their answers, thank them for coming, and adjourn the meeting.

Immediately After Session

Verify if the tape recorder, if used, worked throughout the session. Make any notes on your written notes, e.g., to clarify any scratching, ensure pages are numbered,

fill out any notes that don't make senses, eta.

Usability 26 of 58

Write down any observations made during the session. For example, where did the session occur and when, what was the nature of participation in the group? Were there any surprises during the session? Did the tape recorder break?

Requirement – Individual Interviews

Individual interviews

Face to face, by telephone, through instant messaging or other computer-aided techniques Small numbers: one user at a time Total numbers: usually five to 15 users Rich data — you can follow up on questions Can include both closed and open-ended questions Self-report; good for attitudes, experiences, wish lists Not good for actual behaviors

Individual interviews

What do we mean by individual interviews? Why conduct individual interviews? When should you conduct individual interviews? Individual interviews and focus groups: What's the difference? What makes an interview successful?

What do we mean by individual interviews?

We are using "individual interviews" to refer to talking with one user at a time (for 30 minutes to an hour) face to face or by telephone or with instant messaging or other computer-aided means. These interviews do not involve watching a user work. Thus, this is different from interviewing users in a usability testing session or conducting contextual interviews.

Why conduct individual interviews?

Individual interviews can give you a deep understanding of people who come to your site. You can probe their attitudes, beliefs, desires, experiences. You can ask them to rate or rank choices for the Web site content.

When should you conduct individual interviews?

Use individual interviews to supplement online surveys. You can do interviews first to refine questions for the survey. Or you can do interviews after a survey to probe for details and reasons behind answers that users give on a survey.

Individual interviews and focus groups: What's the difference?

Individual interviews resemble focus groups because they involve talking with users. You do not see them perform work/tasks as you do in usability tests and contextual interviews. The obvious difference between an individual interview and a focus group is that you are talking to one person at a time. In an individual interview,

You have more time to discuss topics in detail You do not have to worry about the group dynamics that inevitably occur in focus groups You can give the interviewee your full attention and you can adjust your interviewing style to draw

out shy users and keep others on topic

What makes an interview successful?

Select participants to represent the types of users you want to come to the Web site. (This is true of all the data-gathering techniques.)

Decide what you want to learn. (This is also true for the other data-gathering techniques.) Write an "interview protocol" for the interviewer to follow. (In focus groups, the comparable

document is called a "script." An interview protocol includes questions and probes to use to follow up on questions.)

Usability 27 of 58

Hire a skilled interviewer who will make interviewees feel comfortable, ask questions in a neutral manner, listen well, know when and how to probe for more details, and keep track of time unobtrusively.

Allow the interviewer flexibility in using the protocol. (Although you want all the questions answered, this is not a survey but can be an opportunity to get a deep understanding of users.)

Get permission to tape the sessions and have one or more people take good notes. (You are looking for answers to the questions and for insights about users that will help you build a Web site that meets their needs.)

Steps in Conducting Interviews

1. Prepare for the interview. Review the application shortly before the interview to refresh your memory. Note areas where you want additional information from the applicant.

2. Set the interview climate. Choose a location free from interruptions and hold all calls. Arrange a casual seating arrangement. Whenever possible, let each candidate see the actual work location. Ensure that appropriate accommodations are made for people who have requested them.

3. Establish rapport. Put the candidate at ease; refer to something you noted on the application to show you have carefully studied it.

4. Set the agenda. Describe the interview structure; this will help you (the panel) and the candidate achieve a concise, focused interview.

5. Take notes. This will help you ask follow-up questions and recall specifics about each candidate. Tell the candidate that you (and the panel) will be taking notes. Note key words/phrases - your notes need not be verbatim. Notes should always be appropriate and reflect job-related observations.

6. Listen Carefully. The applicant should carry 80 to 85 percent of the total conversation. Your input should be limited to asking your prepared questions, probing deeper, and asking follow-up questions as needed.

7. Maintain Control. If the candidate gets off track, ask a specific question that will bring the interview back to the subject.

8. Allow silence and be patient. The candidate may need some time to put his or her thoughts together to provide specific answers to your questions.

9. Avoid using the word "you" during the interview when describing the job. This may be viewed by the applicant as an indication he or she has been selected for the position. For example, do not use, "you will be answering the phone…" Instead change the phrasing so the job is not personalized, e.g., "the job duties for this position are…"

10. Review the listing of Essential Functions. Each applicant should be given a copy of the essential functions. Remind candidates that these may or may not be all of the duties of the position.

11. Ask the applicant to complete the appropriate release forms. For applicable positions, if a background investigation or pre-employment screening will be conducted the applicant must complete the appropriate release form. These release forms can be obtained from Personnel Services prior to the interview.

12. Close the interview. Ask the candidate if he or she has any questions, needs clarification, or has anything to add. Well-prepared candidates will want to ask relevant questions about the job. You may also want to introduce the candidate to others in the office and/or give a tour of the work setting. Thank the candidate for coming and explain your notification process – when a decision will be made, whether a second interview will be conducted, and how candidates will be notified.

13. Complete your notes immediately; don't rely on your memory. Decide whether the candidate meets, exceeds, or does not meet the requirements. Allow adequate breaks between the interviews to make notes and prepare for the next interview

Usability 28 of 58

Requirement – Brainstorming

What is Brainstorming?

Brain storming is one of the oldest known methods for generating group creativity. A group of people come together and focus on a problem or proposal. There are two phases of the activity. The first phase generates ideas, the second phase evaluates them. An experienced facilitator is useful.

Benefits

Although some studies have shown that individuals working alone can generate more and better ideas than when working as a group, the brainstorming activity enables everyone in the group to gain a better understanding of the problem space, and has the added benefit of creating a feeling of common ownership of results.

Planning

Brainstorming is done with a group of people, which may be as small as two, but usually no larger than 12. One of the groups should be nominated as facilitator. It is useful if the facilitator has had previous experience of brainstorming. The group should be assembled, and the facilitator should explain to the group: firstly the problem or idea to be explored; and secondly, the sequence of events that will take place during the method.

There are broadly speaking two phases:a. Nurturant or ideas phase b. Analytical phase.

Nurturant phase

In the nurturant phase, members of the group put forward ideas about the set topic or problem. Be aware of three important issues:

Ensure that everyone in the group has an equal opportunity to put ideas forward Nobody in the group should criticise ideas put forward or attempt to evaluate them in any way All the ideas put forward should be part of a record everyone can see.

Participants may be invited to take turns to present one and only one idea at a time, in a round-the-table fashion. If convenient, post-its may be used as follows:

Every participant has a stack of post-its Participants write down their ideas on their own post-its at any time When it is a person's turn to present an idea, they present the idea on the best of their post-its, and

then fix the post-it onto a wall where everyone else can see it

post-its should initially be arranged in a haphazard fashion.

Alternatively a white-board or computer may be used: anything that will enable the entire group to see what ideas have been generated so far.

The end of the nurturant phase will be apparent, as the speed of ideas slows down.

Step by Step

Define your problem (please note that the word "problem" is not necessarily negative - your problem could be "We need a new product for the Christmas season" or "How can we effectively use our departmental budget surplus for this year?"). Write out your problem concisely and make sure that everyone understands the problem and is in agreement with the way it is worded. There is no need to put a lot of restrictions on your problem at this time.

Give yourselves a time limit - we recommend around 25 minutes, but experience will show how much time is required. Larger groups may need more time to get everyone's ideas out.

Everyone must shout out solutions to the problem while one person writes them out or enters them into BrainStormer. There must be ABSOLUTELY NO CRITICIZING OF IDEAS. No matter how daft, how impossible or how silly an idea is, it must be written down. Laughing is to be encouraged. Criticism is not. Why? Because you want to encourage the free flow of ideas and as soon as

Usability 29 of 58

participants of the brainstorming session begin to fear criticism of their ideas, they'll stop generating ideas. Moreover, Ideas that first seem silly may prove to be very good or may lead to ideas that are very good.

Once your time is up, select the five ideas which you like best. Make sure everyone involved in the brainstorming session is in agreement.

Write down about five criteria for judging which ideas best solve your problem. Criteria should start with the word "should", for example, "it should be cost effective", "it should be legal", "it should be possible to finish before July 15", etc.

Give each idea a score of 0 to 5 points depending on how well it meets each criterion. Once all of the ideas have been scored for each criterion, add up the scores.

The idea with the highest score will best solve your problem. But you should keep a record of all of your best ideas and their scores in case your best idea turns out not to be workable.

The Process Overview

Your team should go through these steps together to define the key user roles for your application. Brainstorm list of roles Identify key characteristics List goals and tasks Create user profiles Create user task scenarios Apply the results

1. Brainstorm a List of User Roles Using a brainstorming approach, list all of the different types of users who need to use your application. These can be based on people you have met, people you have heard about, or just what you believe may be true.

Example: List of User Roles for an Accounting Application

Accounting manager Accounts payable clerk Accounts receivable clerk Accounting analyst Named account specialist

2. Identify the Important Characteristics of the Key User Roles Example: Lists of User Characteristics for Accounting User Roles

User Characteristics for an Accounts Payable Clerk

Training: One week, taken right after implementation

Use of system: Daily, with peak use twice a month

Keyboard/mouse use:     Prefers keyboard for efficiency

 

User Characteristics for an Accounting Manager

Training: None

Use of system: Once a week

Keyboard/mouse use:     Prefers mouse to browse reports

User Characteristics List Use this list to help you think of the characteristics that are important in describing your end-users.

Education and Experience Level: Amount of experience/expertise in the application area (finance, HR, etc.) Amount of experience with R/3 or similar products Amount of experience with computers or operating systems Amount and type of training

Environment and Personal Characteristics:

Usability 30 of 58

Size of company, department and/or group Job description and job title Characteristics of their computer (size of screen, operating system)

Use Characteristics of Product: Frequency of use (how often they use the product per month or week) Duration of use (how long they use the product per session) Number and type of transactions used

User Preferences and Expectations: Expectations for documentation (electronic, web, hard copy, none...) Preferred interaction method (mouse, voice, keyboard)

3. Create a List of Goals and Tasks for Eeach User Role Example: List of Goals and Tasks for an Accounts Payable Clerk

Goals Tasks

Ensure that all accounts are paid at end of month     Run monthly overview report Identify unpaid accounts Contact account owners to arrange payment

Set up new accounts as efficiently as possible Enter new account information Check account info for errors

4. Create User Profiles to Summarize the Information Group the user roles you have listed into categories based on their characteristics and tasks. Select the 3 to 5 key user roles that are the most important users of your application. For each of these key user roles, summarize their important characteristics, goals and tasks in a User Profile. If you have general information about a large number of users who fit this profile, for example, which operating systems they use, you should include it here.

Example User Profile: Accounts Payable Clerk

Education and Experience Level

Amount of experience in accounting:     4 years

Amount of experience with R/3: 2 years

Amount of experience with PCs: 3-5 years

Amount of R/3 training: One week, taken right after implementation

 

Environment and Personal Characteristics

Size of department: 8 people, with 2 accounts payable clerks

Operating system & Monitor screen size:     Windows 95 15-17 inches

   

Use Characteristics of Product

Frequency & Duration of use     Data entry: 5 times per week, for 1-2 hoursReports: 2 times per month, for 2-3 hours

Preferred interaction method: Lots of keyboard-only use during data entry.Prefers keyboard for efficiency.

Goals and Tasks

Goals Tasks

Ensure that all accounts are paid at end of month   Run monthly overview report Identify unpaid accounts Contact account owners to arrange payment

Set up new accounts as efficiently as possible Enter new account information Check account info for errors

Usability 31 of 58

5. Create User/Task Scenarios for the Key Tasks Example Use/Task Scenario: Maintaining Online Documents This scenario applies to the Knowledge Engineer (KEN), which is used by documentation developers at SAP to develop application help. This scenario is based on contextual interview sessions.

User Role:     Documentation Developer

Goal: Ensure that online help is error-free

Task: Fix broken links in help documents

Once a day, the doc. developer looks in CSS for messages about errors in the application help and prints out a list of the current error reports. She also checks MLP mail and voicemail from support centers for error messages, and adds them to the list. She accumulates all the error reports into one list in order to fix them all at once.

Today, many errors of the same type (broken links in the help) have appeared. From past experience, she suspects someone used incorrect syntax for hyper-link definitions in several help screens that were created on the same day.

To fix these broken links, the documentation developer starts the KEN system. She goes to the information object tree and scans it to identify the first document on the list of errors. If she has difficulty identifying the correct object, she refers to a printed copy of her online help project.Once she finds the right object, she downloads the source document. In the help editor (MS-Word), she searches for links using the Search function. When she spots a link that has incorrect syntax, she corrects it and then goes on to the next, again using Search.

Once this process is complete for the first document, she saves the document, and then uploads it. Next, she returns to the object tree and repeats the same steps for the remaining items on today's error list.

6. Apply the User Profiles and User/Task Scenarios Depending on what your needs are you should take one of the following actions with your scenarios:

If you are unsure about the content of these profiles and scenarios, conduct Customer Site Visits to verify them. The Site Visit Workshop (SAP-internal only) and Site Visit Toolkit are available to help you.

If you are re-designing your existing application, use the scenarios and profiles to center your design on particular users and tasks. You can apply this technique in a Design Session.

If you are trying to improve an existing application, use the profiles and scenarios as guides in a Usability Task Review.

If you are preparing to do a Usability Test of your application, use them to identify the right sorts of test participants and to develop test tasks.

Requirement – Evaluating Existing Systems

Benefits

Ensure that all factors that relate to use of the system are identified before design work starts. Provide a basis for designing later usability tests

Method – Planning

A good way to collect the information is to arrange a half-day meeting. Invite stakeholders who have knowledge about the intended users and usage. This may include:

Project manager User representative(s) Developer(s) Training Support

Usability 32 of 58

The first two are key areas. You will also need a facilitator with experience of the method and a person to record the information provided during the meeting. To obtain information on the context of use, a detailed checklist will be needed (see below).

Before the meeting

When using a detailed checklist, to avoid prolonging the meeting it is important to fill in advance any items that are not contentious and highlight the issues that need to be discussed.

Provide all participants with a copy of the checklist.

At the meeting

Discuss and fill in each item on the context checklist. Try to obtain consensus where there is uncertainty or disagreement. If information is missing, agree how this can be obtained. Avoid prolonged discussion of minor issues.

After the meeting

Obtain any missing information. If the information is not easily available, arrange a field study to observe users in their work environment.

Circulate to all participants a summary of the conclusions, and the filled in checklist.

Output

A description of the context of use, derived from the completed checklist

Requirement – Card Sorting

Card sorting –Charastrics

Usually used after gathering information with one or more of the other techniques Each card represents a possible topic on the site Need a start on content topics — so have some cards to sort Usually small numbers: one or two users at a time Typical total numbers: five to 12 users You usually observe and take notes as users talk about what they are doing Can be done remotely with a Web-based tool — so can be large numbers

Card sorting

What is card sorting? What happens in a card sorting session? Why use index cards with one topic per card? How does card sorting work? What about doing card sorting remotely with many users?

What is card sorting?

This is a technique that involves users in grouping information for a Web site. Card sorting helps you build the site's structure and site map, decide what to put on the home page, and label the home page categories.

What happens in a card sorting session?

You give a user (or two users working together) a set of index cards on which you have put likely content topics for the site (one topic per card). The user takes the first card and puts it on the table. The user takes the second card and decides whether it belongs to the same group of information as the first card or if it deserves its own category, etc. — and so on through the set of cards. The user "thinks aloud" during the session and describes his organizing strategy.

Usability 33 of 58

Why use index cards with one topic per card?

To allow users to group — and regroup — the cards. To have users build hierarchies that reflect the categories they want on the home page and how

they would group information in those categories on second-level and lower-level pages.

How Does Card Sorting Work?

Getting the cards ready Arranging for card sorting sessions Conducting a card sorting session Analyzing data

Getting the cards ready

List the content topics or types of information that you are likely to have on the site. (These may come from your objectives for the site, from scenarios you wrote, from what you learned from users with the other data gathering techniques.)

Write each content topic or information type on a separate index card. (Hint: Use slef-adhesive labels and a word processor. These cards will be neat, legible, and consistent. Also, you'll have the list of topics in the computer for easy analysis later.)

Limit yourself to less than 100 cards. (About 50 is a good number.) Have blank cards available for users to add topics and to name the groups they make when they

sort the cards. (Hint: Consider using a different colored card for naming groups.) Number the cards in the bottom corner or on the back.

Arranging for card sorting sessions

Select participants to represent the range of users — pull from different user groups with different levels of experience.

Plan about one hour for each session — longer if you have many cards. Arrange for a space where the user has enough room to spread the cards out on a table. A

conference room works well. Plan to have someone take notes as the user works and thinks aloud. As with other techniques, arrange for payment or other incentives to thank the user for spending

the time and effort helping you.

Conducting a card-sorting session

Show the user the set of cards and explain what you want the user to do. Explain that you are asking for help to find what categories of information should be on the site's home page and what those catagories should be called. Explain that you want to see what groupings of cards make sense to the user and that when the user has grouped the cards, you will ask that they name the groups.

Ask the user to talk out loud while working. (This is the same technique employed use in usability testing.) You want to understand the user's thoughts and rationale.

Let the user work. Also, let the user add cards — for example, to indicate lateral hyperlinks or additional topics. Let the user put cards aside to indicate topics the user would not want on the site. Mimimize interruptions, but encourage the user to think aloud.

At the end, if the user has too many groups for the home page, ask him or her to create hierarchies of the groups.

Give the user a different colored card for each group and ask the user to name the group. What words would the user expect to see on the home page or second-level page that would lead the user to that particular group of cards?

At the end, thank the user and give the user the payment or other gift as promised.

Analyzing data

Use the numbers on the cards to quickly record what that user has done. Write down the names that user gave to each grouping and the numbers of the cards the user included under that name. Then you can reshuffle the cards for the next session.

If you want a complete picture of the detailed site map each user has created, create a computer file for each session. Working from your original list of topics, move topics around to recreate each user's groupings and enter that user's names for the groupings.

Usability 34 of 58

For a less detailed analysis, use your notes and recordings of the users' names and card numbers under each person's name to find commonalities from different sessions.

What about doing card sorting remotely with many users? The National Institute of Standards and Technology (NIST) has developed a tool for card sorting.

You set up the cards, and you name the categories. Users drag and drop cards into the categories.

Requirement – Scenarios of use

Scenarios of use (Use cases) Summary

Scenarios specify how users carry out their tasks in a specified context. They provide examples of usage as an input to design, and provide a basis for subsequent usability testing. They are user- and task-oriented use cases.

Benefits

It encourages designers to consider the characteristics of the intended users, their tasks and their environment.

Usability issues can be explored at a very early stage in the design process (before a commitment to code has been made).

Scenarios can help identify usability targets and likely task completion times. The method promotes developer buy-in and encourages a user-centred design approach. Scenarios can also be used to generate contexts for evaluation studies. Only minimal resources are required to generate scenarios. The technique can be used by developers with little or no human factors expertise.

Method

An experienced moderator is recommended for the sessions in which the scenario is explored.

Gather together the development team and other relevant stakeholders under the direction of an experienced facilitator.

Identify intended users, their tasks and the general context. This information will provide the basis for the scenarios to be created by the development team.

Functionally decompose user goals into the operations needed to achieve them. Consider which activities should be performed by the user and which by the computer. Create an outline of the users' activities, goals and motivations for using the system being

designed, and the tasks they will perform. To maintain design flexibility, scenarios should not specify what product features are used. Assign task time estimates and completion criteria as usability targets. The session can be videotaped for later review or transcribed for wider distribution. The results from scenario building sessions can be used to plan user-based evaluations.

Practical guidelines

Try to generate scenarios to cover a wide range of situations, not just the most common ones or those of most interest to the design team.

Try to include problem situations that will test the system concept, not just straightforward scenarios.

Work through the scenarios fully and judge the system on that basis rather than trying to change the system half way through.

More information

Scenarios are most useful when produced early in development as specific realistic and detailed examples of what a user would do, but without making any reference what user interface features that would be used. Scenarios can also be used later to explore how the interface would be operated.

Next steps

Use the scenarios as a basis for developing more specific usability requirements

Usability 35 of 58

Requirements meeting Summary

A workshop attended by users and developers who identify usability requirements that can be tested later in the development process.

Benefits

Highlights the importance of usability early in development Provides concrete objectives for usability Provides usability criteria that can be tested.

Method 1. Quality in use requirements

Establish requirements for effectiveness, efficiency and satisfaction for the user groups and tasks identified in the context of use analysis and in the scenarios.

Arrange a workshop attended by: User(s) Developer(s).

You will also need a facilitator and a person to record the issues raised during the meeting.

Review each of the tasks in the context analysis report along with their associated task scenarios to confirm their relevance and importance.

Decide which task(s) and user type(s) needed usability criteria.

For each chosen task and user type estimate: The acceptable task time and the optimum target How to score effectiveness by agreeing what errors the user might make The effectiveness target The satisfaction target.

If there is an existing system, it can be evaluated by the selected users and tasks, and the results used to refine the usability requirements. Quality in use requirements should be evaluated by usability testing.

More information on quality in use requirements. More information on setting criteria for effectiveness, efficiency and satisfaction can be found in ISO 9241-11: Guidance on usability, and ISO/IEC 9126-4: Quality in use metrics ("quality in use" is defined is a similar way to "usability" in ISO 9241-11).

2. Detailed usability requirements

Decide which usability requirements are relevant. Examples of potential requirements are:

Understandability Interface elements (e.g. menus) should be easy to understand For a walk up and purchase or use system, the purpose of the system should be easily

understandable

Learnability The user documentation and help should be complete The help should be context sensitive and explain how to achieve common tasks The system should be easy to learn

Operability The interface actions and elements should be consistent Error messages should explain how to recover from the error Undo should be available for most actions Actions which cannot be undone should ask for confirmation The system be customisable to meet specific user needs A style guide should be used

Usability 36 of 58

Attractiveness The screen layout and colour should be appealing

Arrange a workshop to review how to elaborate the requirements for the specific system being developed. The workshop should be attended by:

Developer(s) User(s) if easily available

You will also need a facilitator and a person to record the issues raised during the meeting. Usability requirements should be evaluated when testing a paper or machine prototype.

Example The Microsoft Windows style guide will be adhered to. Error messages must give the user specific instructions for recovery. The help system will explain all functions and how to achieve common tasks. Users will be able to consistently locate appropriate help information. All keyboard shortcuts will be customisable

Requirement – Task Analysis

Summary

Task analysis analyses what a user is required to do in terms of actions and/or cognitive processes to achieve a task. A detailed task analysis can be conducted to understand the current system and the information flows within it. These information flows are important to the maintenance of the existing system and must be incorporated or substituted in any new system. Task analysis makes it possible to design and allocate tasks appropriately within the new system. The functions to be included within the system and the user interface can then be accurately specified.

Benefits

Provides knowledge of the tasks that the user wishes to perform. Thus it is a reference against which the value of the system functions and features can be tested.

Method - Task decomposition

The aim of ‘high level task decomposition’ is to decompose the high level tasks and break them down into their constituent subtasks and operations. This will show an overall structure of the main user tasks. At a lower level it may be desirable to show the task flows, decision processes and even screen layouts (see task flow analysis, below)

The process of task decomposition is best represented as a structure chart (similar to that used in Hierarchical Task Analysis). This shows the sequencing of activities by ordering them from left to right. In order to break down a task, the question should be asked ‘how is this task done?’. If a sub-task is identified at a lower level, it is possible to build up the structure by asking ‘why is this done?’. The task decomposition can be carried out using the following stages:

Identify the task to be analysed. Break this down into between 4 and 8 subtasks. These subtasks should be specified in terms of

objectives and, between them, should cover the whole area of interest. Draw the subtasks as a layered diagram ensuring that it is complete. Decide upon the level of detail into which to decompose. Making a conscious decision at this stage

will ensure that all the subtask decompositions are treated consistently. It may be decided that the decomposition should continue until flows are more easily represented as a task flow diagram.

Continue the decomposition process, ensuring that the decompositions and numbering are consistent. It is usually helpful to produce a written account as well as the decomposition diagram.

Present the analysis to someone else who has not been involved in the decomposition but who knows the tasks well enough to check for consistency

Usability 37 of 58

Requirement – Requirements Meeting

Summary

A workshop attended by users and developers who identify usability requirements that can be tested later in the development process.

Benefits

Highlights the importance of usability early in development Provides concrete objectives for usability Provides usability criteria that can be tested.

Method

Establish requirements for effectiveness, efficiency and satisfaction for the user groups and tasks identified in the context of use analysis and in the scenarios.

Arrange a workshop attended by:

User(s) Developer(s).

You will also need a facilitator and a person to record the issues raised during the meeting.

Review each of the tasks in the context analysis report along with their associated task scenarios to confirm their relevance and importance.

Decide which task(s) and user type(s) needed usability criteria.

For each chosen task and user type estimate:

The acceptable task time and the optimum target How to score effectiveness by agreeing what errors the user might make The effectiveness target The satisfaction target.

If there is an existing system, it can be evaluated by the selected users and tasks, and the results used to refine the usability requirements. Quality in use requirements should be evaluated by usability testing.

Prototype - Design Guidelines

Summary

Guidelines for user interface design summarise good practice and provide useful high and low level guidance on the design of usable interfaces. Adherence to specific guidelines can be specified as part of the usability requirements. Designers and developers should then familiarise themselves with the relevant guidelines, and expert evaluation should be used to check for compliance with the most important guidelines.

Benefits

Guidelines embody good practice in interface design. Following usability guidelines will improve the quality of the interface.

Contents

Intended audience, purpose, advantages of use are indicated. Tag line describes value of site to user; distinguishes organization from competitors. Each page indicates site ID, logo, page name, major sections, options at current level. Home page spells out "big picture: what it is, what it contains, what users can do, why users should

be there.

Usability 38 of 58

Sponsoring institution is indiciated, its philosophy described, and credibility established. The funding agency is identified.

Samples provided before users must register. Each page is self-evident, or at least self-explanatory. All information presented is important. Importance is evident to user. Page is designed to be scanned rather than read. Limit text whenever possible. Plain language is used throughout. Meaningful content is provided within three seconds of page download. Entire page loads within six seconds-"six second rule." Policy for treatment of user's personal information is specified. FAQs are provided for common problems. E-mail contact is provided for user support.

Graphic Design

Site is designed for the users' monitor size, download speeds, browser and plug-ins. Unique and consistent look and feel are evident throughout Page download time is minimized through use of modest graphical elements. Visual noise and clutter are avoided. Visual hierarchy matches content hierarchy. Adequate contrast provided between foreground and background, for color-impaired vision and

printing. Limited number of fonts used; fonts used are those commonly installed. ALL CAPS and all italics are used sparingly; underlined text is reserved to denote links.

Navigation

Navigational controls and search function are standardized across the site, conform to established convention.

Primary information and navigation controls are displayed at top left of page. Structure of site, and current location, are easy to ascertain from appearance of navigational

controls. Flexible navigation options are provided (more than one path through the woods). Home page provides "short-cuts" to frequently needed features. Home page is available from all pages. Users can 'backward chain," to retrace their steps. Every page is "bookmark-able." The clicks to get to desired information and functions are painless (easy to understand what

options to select). The number of clicks to get to desired functions is minimized.

Functions

Navigational controls and search function are standardized across the site, conform to established convention.

Primary information and navigation controls are displayed at top left of page. Structure of site, and current location, are easy to ascertain from appearance of navigational

controls. Flexible navigation options are provided (more than one path through the woods). Home page provides "short-cuts" to frequently needed features. Home page is available from all pages. Users can 'backward chain," to retrace their steps. Every page is "bookmark-able." The clicks to get to desired information and functions are painless (easy to understand what

options to select). The number of clicks to get to desired functions is minimized.

Usability 39 of 58

Prototype - Paper Prototyping

Introductory articles

Basic methods: paper prototypingA short overview of paper prototyping.

How good does your website look on paper?The best way to improve the effectiveness of your company's web site is to let your site's users lend you a hand (quite literally) through the process of paper prototyping. Paper prototyping is a fast, low-cost method of testing web site designs. It involves creating rough sketches of a web site design and inviting some of your users to take the design for a test drive using their pen, instead of a mouse, to complete important tasks.

Paper prototypingA short discussion of paper prototyping and a set of scaled GUI and web screens and labels and buttons for controls such as fields and form buttons.

Paper prototypingThis method features the use of simple materials and equipment in order to create a paper-based simulation of an interface or system. Paper prototypes provide a valuable and cost-effective means to evaluate and iterate design options before a team gets committed to one implementation. Interface elements such as menus, windows, dialogues and icons can be sketched on paper or created in advance using card, acetate, pens etc. The result is sometimes referred to as a low-fidelity prototype.

Recommended methods: paper prototypingOverview of paper prototyping in point form.

Testing with a paper prototypeA brief overview of usability testing using paper prototypes.

Purpose

To enable draft interaction designs and screen designs to be very rapidly simulated and tested.

Benefits

Potential usability problems can be detected at a very early stage in the design process before any code has been written.

Communication between designers and users is promoted. Paper prototypes are quick to build / refine, thus enabling rapid design iterations. Only minimal resources and materials are required.

Four stages of paper prototyping may be required:

Concept design: to explore different metaphors and instructional strategies Interaction design: to organise the structure of screens or pages Screen design: for initial design of each individual screen Screen testing: to refine the screen layout

Concept design

Sit round a table and sketch out possible approaches in a brainstorming environment. Evaluate the extent to which each approach meets the objectives agreed in the stakeholder

meeting

Interaction design

Brainstorm possible screens or page types based on user tasks. Write the name of each suggested screen or page on a post-it-note. Put each post-it-note on the wall close to related notes.

Usability 40 of 58

Group the post-it-notes in clusters that are meaningful to users. Consolidate duplicates. Give a name to each cluster.

Screen design

Sit round a table and sketch out design ideas in a brainstorming environment. Use this as a basis for rough sketches of each screen. If the links between screens have not been finalised, pin each screen on the wall as for Interaction

Design above, Ask the user to carry out a realistic task (based on the scenarios defined at the stakeholder

meeting) As the user selects options on each screen, the developer explains what happens, and either

points to the next screen or presents the next screen to the user (without giving any hints on how to complete the task).

Screen testing

Produce a rough design for each screen drawn by hand, or using a drawing package or prototyping tool.

If the links between screens have not been finalised, pin each screen on the wall as for Interaction Design above.

Ask the user to carry out a realistic task (based on the scenarios defined at the stakeholder meeting).

As the user selects options on each screen, the developer explains what happens, and either points to the next screen or presents the next screen to the user (without giving any hints on how to complete the task).

To test more detailed interaction, prepare pieces of paper with menus, scroll boxes, dialogue boxes, etc., and present these to the user when they select the appropriate option.

The user simulates pointing and clicking using a pencil, and simulates typing by writing on paper.

How Good Does Your Web Site Look on Paper?

Navigation/Flow

Paper prototyping is an ideal method for testing the navigation and flow of a web site. Users can help you determine whether organization of the web site is intuitive and whether the terminology used in the navigation makes sense.

Content

Paper prototypes are a good way to test the effectiveness of content within the site. You can identify whether the content and writing style used within the site is appropriate. Users often help identify content this is missing, unclear, or unnecessary.

Layout

Hand-drawn designs allow users to provide a wide range of feedback. They can help you determine if pages contain too little or too much information, and whether the general layout of the page is effective.

Functionality/Interactivity

By providing users with simulations of interactivity in the site, you can determine whether proposed functions will be utilized and valued by users. For example, it can help determine whether a "do it yourself" planning tool will be used by site visitors.

It only takes 6-8 customers using a paper prototype to identify prevent more than 80 percent of these kinds of high level problems that occur within web sites. Since the goal of paper prototyping is to achieve the most effective, customer-friendly site, it's not surprising that sites employing paper prototypes earn a higher user satisfaction rating.

Usability 41 of 58

However, customers aren't the only ones who benefit. Companies using paper prototypes can implement sites more efficiently, allowing them to complete projects faster at a lower cost.

Summary description

This method features the use of simple materials and equipment in order to create a paper-based simulation of an interface or system. Paper prototypes provide a valuable and cost-effective means to evaluate and iterate design options before a team gets committed to one implementation. Interface elements such as menus, windows, dialogues and icons can be sketched on paper or created in advance using card, acetate, pens etc. The result is sometimes referred to as a low-fidelity prototype. When the paper prototype has been prepared a member of the design team sits before a user and ‘plays the computer’ by moving interface elements around in response to the user’s actions. The user makes selections and activates interface elements by using their finger as a mouse and writing ‘typed’ input. A further person facilitates the session by providing task instructions and encouraging the user to express their thoughts and impressions. Notes may be made by other observers or a video record may be created.

Typical Application Areas

The method has wide applicability. However, it is most suitable in contexts where it is easy to simulate system behaviour or when the evaluation of detailed screen elements is not required. Paper prototyping is appropriate for the early stages of the design cycle where changes can be readily made before there is a commitment to one implementation.

Benefits

Usability problems can be detected at a very early stage in the design process (before a commitment to code has been made).

Communication and collaboration between designers and users is encouraged.

Paper prototypes are quick to build and refine, and thus support iterative design and multiple evaluations.

Only minimal resources and materials are required to convey product feel.

The technique can be utilised by those with little or no human factors expertise.

Limitations

Because of their simplicity, paper prototypes do not support the evaluation of fine design detail. Due to the use of paper and a human operator, this form of prototype can not be reliably used to simulate system response times.

The individual playing the role of the computer must be fully aware of the functionality of the intended system in order to simulate the computer.

Cost of use

The technical resources required are minimal. Materials such as paper, card, adhesives and markers are needed to create the actual prototype. In addition, some means of recording the interactions between user and prototype is required (e.g. video camera). The method also needs one individual to play the role of the computer or system, and another to act as a facilitator. Costs may also be incurred when recruiting users and allocating time to manage each evaluation session.

Detailed description of method

The following material outlines firstly a general procedure for implementing this method, and also indicates the kind of information that is produced. Then a more detailed overview of two activities that can be carried out with paper prototyping is given: sketching and user testing.

1. Firstly, allow enough time to cre ate the prototype, design some tasks, recruit users, conduct the evaluation of the prototype and report the results.

2. Assemble the necessary materials. Construct the paper prototype, using separate stock for menus, dialogue boxes and any element that moves or changes appearance.

Usability 42 of 58

3. Select appropriate users to test the prototype, try to cover the range of users within the target population.

4. Prepare realistic task scenarios for the evaluation. 5. Pilot the evaluation procedure and practice playing the role of the computer. 6. Ensure recording facilities are available and functioning. 7. Conduct each session, by manipulating the paper prototype as the users work through the tasks. 8. The facilitator provides the task instructions and explores the user’s impressions and intentions

through appropriate questions. 9. If observers are present they can make notes of problem areas and potential solutions on cards

during the session for later scrutiny and prioritisation. 10. Conduct post-session interviews with the users, drawing upon pre-set questions and issues raised

during the prototype evaluation. 11. Debrief the users and thank them for their co-operation. 12. Analyse information obtained, summarise observations and user evaluations. Consider the themes

and severity of the problems identified. 13. Summarise design implications and recommendations for improvements and feed back to design

team. The video recordings can support this. 14. Where necessary refine the paper prototype and repeat the above process

The evaluation of paper prototypes provides an opportunity to collect early design feedback. This results in recommendations for the refinement of the initial prototype, which can form the basis for the evaluation of further prototypes.

Sketching

This technique involves members of the design team and potential users, producing sketches or designs of the ideas that they wish to input to the design process. The objective is to enhance user participation in the design process and collaboration between designers and users. The easiest way to set up a sketching exercise is to use a flipchart or whiteboard with everyone sitting around it presenting and reacting to ideas. An electronic whiteboard has the advantage of producing printouts of the ‘screen’ which can then be photocopied to the group before rubbing out the earlier ideas to consider new ones (e.g. SILK Landey 1994). Alternatively, users may sketch their own ideas individually which they can then each present in turn to the group.

A more sophisticated method involves presenting users with a set of paper, cardboard or plastic interface elements which they can lay out, on a flat surface, in what they feel is an appropriate way. Again designs may be discussed and developed as a group or individually. An example of such a kit is PICTIVE created at Bellcore by M. Muller (1992). This method is effective when the basic control types of a future interface are known but user feedback on a suitable layout is required. The method does not require users to draw the interface although they can supplement the design with additional elements or annotations to add contents.

The success of the exercise relies on the presence of a facilitator chairing the meeting. The main role of this person is to ensure that the group stay focused upon the design problem and ensuring that every member of the group is given the opportunity to stand up and present his or her own ideas. Another role is to summarise all the ideas after the session for presentation to a design team meeting.

The outcome of a participatory design exercise will be a series of ideas for screens, layouts, navigation structure, that can be evaluated by the design team to assess their technical feasibility and usability. They will thus serve as a first draft of design specifications. Various techniques are possible to preserve the designs : the sessions can be recorded on video, the paper mockups may be stuck down onto a base sheet, covered with clear plastic, photographed or simply photocopied. They may then be mocked-up on screen or in hardware form to further test the ideas. The paper screen designs can also be used as a ‘walk-through’ exercise to get reactions from other end users.

User testing

Early pilot studies of a system idea can be carried out using paper versions of screen displays. These tests can be run to compare design alternatives, or to contrast with current procedures. The paper-prototype should be designed to contain the screens or interactive sequences needed to perform a series of typical tasks. During the test, a member of the design team sits in front of a user and ‘plays the computer’ by moving interface elements around in response to the user’s actions. Alternatively they may write messages on ‘post-its’ to represent elements such as pull down menus or dialogue boxes. The user makes selections and activates interface elements by using their finger as a mouse and writing ‘typed’ input. A further person

Usability 43 of 58

facilitates the session by providing task instructions and encouraging the user to express their thoughts and impressions. Notes may be made by other observers or a video record may be created.

A variant of the paper walkthrough is to produce the screens as a set of cards. Users are asked to order the cards in the sequence that seems most appropriate for the activities they must carry out. The objective is to focus on the flow of user tasks and identify the appropriate structure of the task-sequence. (e.g. CARD: Collaborative Analysis of Requirements and Design, M.Muller 1992). Cards may also be used to elicit data or menu structures from the user. Each of the data elements or menu options may be written out on cards and laid out infront of the user. The user then places the cards into piles to represent suitable groupings. Common groupings between different user subjects can be used to structuring the system data or menus. The method is particularly useful for assessing user reactions to layout, data structures, and sequencing of screens. However it is hard to convey to the user the feeling of interacting with the new system.

The tests allow usability problems to be detected and recommendations be made at a very early stage in the design process, before a committing the design to code. Thus it supports iterative design and multiple evaluations. Further redesign can be carried out on paper, or the design can be developed on screen to test the dynamic interactive features.

Prototype - Heuristic EvaluationHeuristic evaluation is a discount usability engineering method for quick, cheap, and easy evaluation of a user interface design.

Heuristic evaluation is the most popular of the usability inspection methods. Heuristic evaluation is done as a systematic inspection of a user interface design for usability. The goal of heuristic evaluation is to find the usability problems in the design so that they can be attended to as part of an iterative design process. Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the "heuristics").

What is Heuristic Evaluation?

Heuristic Evaluation (originally proposed by Nielsen and Molich, 1990) is a discount method for quick, cheap, and easy evaluation of the user interface.

The process requires that a small set of testers (or "evaluators") examine the interface, and judge its compliance with recognised usability principles (the "heuristics"). The goal is the identification of any usability issues so that they can be addressed as part of an iterative design process.

Heuristic Evaluation is popular in Web development circles because it requires few resources in terms of money, time or expertise. So any developer can enjoy the benefits of usability testing - not just those with thousands to spend on a professional assessment. Heuristic Evaluation is characterised by:

Small test scenarios that use paper mock-ups or screen shots, which can easily be changed from one test situation to the next

An informal basis for assessment that doesn't require psychologists A high success rate - so only a handful of testers are needed A few key guidelines

How can I Use Heuristic Evaluation on my Site?

1. Plan Your EvaluationHow will you test your interface? Heuristic Evaluation typically employs one of the three main approaches:

2. Develop a set of tasks and ask your evaluators to carry them out. Identify and test the tasks that are critical to your site's success - you'll want all visitors to be able to perform these - and any elements expected to cause difficulty for your site visitors.

3. Provide evaluators with the goals of the system, and allow them to develop their own tasks.

Usability 44 of 58

An example goal might be "users should be able to find out how much product x costs." Evaluators can then break this goal down into appropriate tasks, and test each in turn.

4. Ask evaluators to assess your dialogue elements.Ask evaluators to go through the interface a number of times and examine and assess the efficacy of those elements of your Website that contribute to a dialogue with your site visitors.

Choosing which method to use will depend on you, the time that you have available, and on your evaluators. For example, if you were evaluating with young children, the most appropriate method would be to develop a set of tasks and ask them to carry them out. Children will find this much more achievable than trying to develop their own tasks, or assessing your Website elements without any obvious aims.

Choose your Evaluators

The more evaluators you use, the more usability problems you'll reveal. However, studies on the subject have shown that the benefit/cost ratio decreases at about five evaluators. So who should these evaluators be?

Those with experience - if you can find 5 evaluators who are experts in software ergonomics, and in the field in which the software is applied, a well-planned evaluation program will typically find 81%-90% of usability problems with your interface

Those without experience - if you don't have 5 free experts at your fingertips, don't worry. A student with no knowledge of software ergonomics will find 22% to 29% of usability problems. Heuristic Evaluation is known to find more than 90% of usability problems if it's performed by 3 to 5 experienced people... but remember, one evaluator is better than none!

Heuristic Evaluation - a Step By Step Guide

Review the HeuristicsOnce you've decided which approach you'll take, and you've selected your evaluators, you'll need to brief these people on the ten heuristics you want them to assess your site against. Note: Examples of what they should look out for can be found in the Useful Websites section at the end of this article.

Visibility of System StatusProbably the two most important things that site visitors need to know are:

o Where am I?" and o Where can I go next?"

So it's essential that your interface keeps users informed about what's going on. To test this, your evaluators should look for appropriate feedback within a reasonable time following each user interaction.

For example, once a user clicks the 'Submit' button on your order form, within a few seconds they'll require feedback that tells them their order has been received. This feedback might appear in the form of a separate page, or popup, which also contains a 'back to site' link indicating where the user can go next.

Match Between the System and the Real WorldThe system should speak the users' language, using words, phrases and concepts that are familiar to the user, rather than system-oriented terms. Even though you might use what is considered standard jargon for the topic on which your site focuses, consider including a further simplification or explanation of the words you've used.

Your evaluators should make sure you've followed real-world conventions, and that your information appears in a natural and logical order. A real world concept applied on the Web is the shopping cart. On many sites, you click once to select an item (the equivalent of picking it up off the shelf in a real store), click again to "add to basket" (or place it in your trolley) and then a third time to confirm your intention to buy (or move to the checkout).

User Control and Freedom

Usability 45 of 58

Site visitors often choose system functions by mistake, and will need a clearly marked "emergency exit" to leave the unwanted page without having to go through an extended dialogue. While there's a definite need for order to exist in your site, a greater degree of user control may be required to cater to the needs of more experienced users.

Your evaluators should ensure that your site meets the control requirements of both first-time and experienced users. An example of a control element might be a "home" button that appears on every page. It's a simple way to let users feel in control of the system - they know they can "go home" (or opt-out) at any stage in the process.

Consistency and StandardsUsers should not have to wonder whether different words, situations, or actions mean the same thing. it's best to follow the uniform and/or platform conventions to which your users are accustomed.

If the user want to return to the main page then label your link "Home" or "Homepage", rather than some obscure reference.

Error PreventionEven better than good error messages is a careful design that prevents a problem from occurring in the first place.

The best way to avoid errors is to conduct testing, more testing, and even more testing. However, if errors do occur, try to provide user friendly messages in natural language rather than code.

Recognition Rather than RecallMake sure objects, actions, and options are highly visible. Your site visitors shouldn't have to remember information between different parts of their dialogue with your site. Instructions for use of the system should be visible - or at least easily retrievable - whenever your users need them. This increases the chance that your visitors will be able to recognise where they are, so they won't have to retrace their path from the home page.

For example, if you create a Website with a lot of submenus, then use a system that will let the users know what section they are in at all times. You could do this by leaving a breadcrumb trail, or maybe applying a color scheme that differentiates the various sections.

Flexibility and Ease of UseAccelerators, which may be unseen by the novice user, can often speed up the interaction for the expert user, and allow the system to cater to both types of visitors. You might, for instance, allow users to tailor frequent actions.

Take Amazon. They save the personal information that's provided by customers upon purchase. Then, each time the customer makes another purchase, they can retrieve their information with a single click. In this way, Amazon provides customers with a way to avoid filling in an extensive form each time they buy a product at the store.

Aesthetic and Minimalist DesignExtraneous information on a page is a distraction and a slow-down. Make rarely needed information accessible via a link so that the details are available, but don't interfere with the more relevant content.

If your "Contact Us" page contains a form, as well as all your physical contact details such as address, telephone number etc., there's no need to also include a map with extensive instructions on how to get to your premises. Instead, this can be provided on a linked but separate page - not everyone who fills out the contact form will wish to see the map every time they visit the page.

Help Users Recognise, Diagnose, and Recover from ErrorsErrors will occur despite all your efforts to prevent them. Your error messages should be expressed in plain language with no codes or jargon. They should detail the problem, and constructively suggest a solution.

Usability 46 of 58

For example, if a form is completed incorrectly, your error message should alert your visitor to this, identify which fields will need to be refilled, and perhaps highlight those fields when the user returns to complete the form after they dismiss the error message.

Help and DocumentationIdeally, every online system could be used without documentation, However, it may be necessary to provide help and documentation to cater to the needs of all users, and be on the safe side.

Your evaluators should check to make sure that help and other documentation:o Is easy to search o Focuses on the user's task o Lists the concrete steps users need to carry out to achieve their goals o Isn't too large

Often, documentation is fully integrated into a Website. There should be links from the main help sections into specific subsections, and vice versa. Help could even be fully integrated into each page so that users never feel like assistance is too far away.

Conducting the Evaluation

Conduct the evaluation using either of these methods:

Individual Evaluation - each evaluator reviews the interface individually and reports problems to you. Individual evaluation is easily conducted over the Internet. It will pick up more problems than group evaluation, but takes a lot more time to complete.

Group Evaluation - evaluators review the interface as a team, while you record the problems. Evaluators do not have to agree on a problem - but every issue they identify should be recorded. Group evaluation requires more planning than does individual evaluation, as all evaluators need to be assembled, however, the evaluation need only be conducted once as all the evaluators can complete their tasks at the same time.

The most basic form of evaluation is to choose a random page from your site and see if your evaluators can: Tell where they are Tell what they can/should do next

Analysing your Results

Once your evaluators have: Worked their way through the tasks or goals you set, Evaluated each of these in light of the ten heuristics, and Provided their feedback,

You'll need to compile all the information. Remove any duplicates and combine similar issues. What's left will be a set of problems or comments that you can address to improve your site's usability.

Remember the Golden Rule!

The golden rule of usability is:

There's no such thing as a "user error"!

Make sure you clarify every problem your evaluators identify - ask questions so that you understand the specific nature of the difficulties they encountered. And remember:

Don't argue with your evaluators, Don't try to "explain away" problems they identified

If an evaluator found an aspect of your site confusing, then it's more than likely that your Website visitors might have problems with it too.

Usability 47 of 58

The following 0 to 4 rating scale can be used to rate the severity of usability problems:

0 = I don't agree that this is a usability problem at all1 = Cosmetic problem only: need not be fixed unless extra time is available on project2 = Minor usability problem: fixing this should be given low priority3 = Major usability problem: important to fix, so should be given high priority4 = Usability catastrophe: imperative to fix this before product can be released

Prototype - Parallel Design

Summary

Parallel design is a method where alternative designs, often interface designs, are created by two to four design groups at the same time. The aim is to assess the different ideas before settling on a single concept for continued development. The design groups work independently of each other, since the goal is to generate as much diversity as possible. Design groups should not discuss their designs with each other until after they have produced their draft design concepts and presented them in a design workshop. The final design may be one of the designs or a combination of designs, taking the best features from each.Although parallel design might at first seem like an expensive approach, since many ideas are generated without implementing them, it is a very cheap way of exploring a range of possible concepts before selecting the probable optimum.

Benefits

Allows a range of ideas to be generated quickly and cost effectively. Parallel nature of the approach allows several approaches to be explored at the same time, thus

compressing the concept development schedule. The concepts generated can often be combined so that the final solution benefits from all ideas

proposed. Only minimal resources and materials are required to convey product feel. The technique can be utilised by those with little or no human factors expertise. However, parallel design requires a number of design team members to be available at the same

time to produce the concepts and it requires a lot of time to be invested over a short period for the design work to be carried out. Also, time must be allocated to compare parallel design outputs properly so that the benefits of each approach are obtained.

Method

The method requires design team members to be available concurrently in order to carry out design work in parallel. A requirements document is needed to make sure that the design groups are given the same information so that design work starts from the same starting point.

1. The following procedure may be adopted for implementing this method:2. Define clearly the boundaries for the parallel design, i.e. goal of system, tasks that it should

support, user characteristics, etc. Each design team should receive the same set of requirements before starting the design activity..

3. Each design teams may use whatever media they prefer to present their designs. It is recommended to use a low level of prototyping. No extra points should be given for ‘sophisticated’ prototypes.

4. Design teams should have roughly equivalent skills. 5. Decide beforehand how much time to allocate to the design work and set a clear time limit. 10 - 20

hours per group is often sufficient. 6. Agree on the criteria by which the designs will be assessed. 7. Allow sufficient time to carry out a fair comparison of the designs produced. This is often carried out

in a design workshop, where all groups and their member participate. 8. Discuss each design separately and then discuss how different aspects of the designs may be

combined. 9. The objective is to settle on one design concept based on the total effort.

Usability 48 of 58

Evaluate prototype

Summary Participative user based evaluation of a paper or machine prototype to identify usability problems, where the user is probed to explain their expectations and problems.

Benefits Potential usability problems can be detected at an early stage before development is complete. A deeper understanding of the users' expectations and impressions of the system.

Method - Planning Select the most important tasks and user group(s) to be tested (e.g. the most frequent or the most

critical). Select users who are representative of the user group(s). 3-5 users are sufficient to identify the

main issues. Consider using user-defined tasks, where users are asked to define their own goals prior to the

evaluation session. Produce task scenarios and input data and write instructions for the user (tell the user what to

achieve, not how to do it). Plan sessions allowing time for giving instructions, running the test, and a post-test interview. Invite developers to observe the sessions if possible. An alternative is to videotape the sessions,

and show developers edited clips of the main issues. For a paper prototype a designer is needed to play the role of "computer".

Running sessions Welcome the user, and give the task instructions. For a paper prototype, as the user selects options on each screen, the designer explains what

happens, and either points to the next screen or presents the next screen to the user. Do not give any hints or assistance unless the user is unable to complete the task. Observe the interaction and note any problems encountered. The user may be prompted for their impressions of a page design, what they think different

elements may do, and what they expect the result of their next action to be. The user may also be asked to suggest how individual elements could be improved.

Interview the user to gain general opinions, and to ask about specific problems encountered.

Output Produce a list of usability problems, categorised by importance (use sticky notes to sort the

problems), and an overview of the types of problems encountered. Arrange a meeting with the designers to discuss whether and how each problem can be fixed.

Prototype - Evaluate Prototype

Purpose

To obtain rapid feedback on the usability of prototypes..

Benefits

Potential usability problems can be detected at an early stage before development is complete.

Method

A simplified version of usability testing is used. Only 3-5 users are required, and it is usually best to prompt the user to explain their interpretation of the contents of each screen and their reason for making choices. However, if estimates of usability measures are required, ask the user to think aloud, but do not interrupt them.

Usability 49 of 58

Reporting

Produce a list of usability problems, categorised by importance (use post-it-notes to sort the problems), and an overview of the types of problems encountered.

Arrange a meeting with the project manager and developer to discuss whether and how each problem can be fixed.

Usability Testing - Dignostic Evaluation

Summary

User based evaluation of a working system, where the primary objective is to identify usability problems.

Benefits

Major usability problems are identified. An understanding is gained of why the user has difficulties with the system. Approximate measures can be obtained for the users' effectiveness, efficiency and satisfaction.

Method Planning

It is important that the users, tasks and environment used for the test are representative of the intended context of use.

Select the most important tasks and user group(s) to be tested (e.g. the most frequent or the most critical).

Select users who are representative of the user group(s). 3-5 users are sufficient to identify the main issues. 8 or more users of each type are required for reliable measures. For complex systems such as an e-commerce web site, larger numbers may be require to explore all aspects of the system.

Consider using user-defined tasks, where users are asked to define their own goals prior to the evaluation session.

Produce task scenarios and input data and write instructions for the user (tell the user what to achieve, not how to do it).

Plan sessions allowing time for giving instructions, running the test, answering a questionnaire, and a post-test interview.

Invite developers to observe the sessions if possible. An alternative is to videotape the sessions, and show developers edited clips of the main issues.

Two administrators are normally required to share the activities of instructing and interviewing the user, operating video equipment (if used), noting problems, and speaking to any observers.

If possible use one room for testing, linked by video to another room for observation. If usability measures are required, observe the user without making any comments. If measures are not required, prompt the user to explain their interpretation of the contents of each

screen and their reason for making choices.

Running sessions

Welcome the user, and give the task instructions. Do not give any hints or assistance unless the user is unable to complete the task. Observe the interaction and note any problems encountered. If required time each task. Either ask the user to think aloud, or prompt the user to explain their interpretation of the contents

of each screen and their reason for making choices. At the end of the session, ask the user to complete a satisfaction questionnaire. Interview the user to confirm they are representative of the intended user group, to gain general

opinions, and to ask about specific problems encountered. Assess the results of the task for accuracy and completeness.

Output

Produce a list of usability problems, categorised by importance , and an overview of the types of problems encountered.

Arrange a meeting with the project manager and developer to discuss whether and how each problem can be fixed.

Usability 50 of 58

If measures have been taken, summarise the results of the satisfaction questionnaire, task time and effectiveness (accuracy and completeness) measures.

If a full report is required, the Common Industry Format provides a good structure.

Usability Testing - Performance Testing

Performance testing Summary

Performance testing is a rigorous usability evaluation of a working system under realistic conditions to identify usability problems and to compare measures such as success rate, task time and user satisfaction with requirements.

Benefits

Major usability problems are identified that may not be revealed by less formal testing, including problems related to the specific skills and expectations of the users. Measures can be obtained for the users' effectiveness, efficiency and satisfaction.

Method Planning

It is important that the users, tasks and environment used for the test are representative of the intended context of use.

Select the most important tasks and user groups to be tested (e.g. the most frequent or the most critical).

Select users who are representative of each user group. 3-5 users are sufficient to identify problems. 8 or more users of each type are required for reliable measures.

Produce a task scenario and input data and write instructions for the user (tell the user what to achieve, not how to do it).

Plan sessions allowing time for giving instructions, running the test, answering a questionnaire, and a post-test interview.

Invite developers to observe the sessions if possible. An alternative is to videotape the sessions, and show developers edited clips of the usability problems.

Two administrators are normally required to share the activities of instructing and interviewing the user, operating video equipment (if used), noting problems, and speaking to any observers.

If possible use one room for testing, linked by video to another room for observation. If usability measures are required, observe the user without making any comments. If measures are not required, prompt the user to explain their interpretation of the contents of each

screen and their reason for making choices.

Running sessions

Welcome the user, and give the task instructions. Do not give any hints or assistance unless the user is unable to complete the task. Observe the interaction and note any problems encountered. Time each task. At the end of the session, ask the user to complete a satisfaction questionnaire. Interview the user to confirm they are representative of the intended user group, to gain general

opinions, and to ask about specific problems encountered. Assess the results of the task for accuracy and completeness.

Output

Produce a list of usability problems, categorised by importance , and an overview of the types of problems encountered.

Arrange a meeting with the project manager and developer to discuss whether and how each problem can be fixed.

If measures have been taken, summarise the results of the satisfaction questionnaire, task time and effectiveness (accuracy and completeness) measures.

If a full report is required, the Common Industry Format provides a good structure

Usability 51 of 58

Usability Testing - Heuristic EvaluationHeuristic evaluation is the most popular of the usability inspection methods. Heuristic evaluation is done as a systematic inspection of a user interface design for usability. The goal of heuristic evaluation is to find the usability problems in the design so that they can be attended to as part of an iterative design process. Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the "heuristics"). Summary

Heuristic evaluation is a form of usability inspection where usability specialists judge whether each element of a user interface follows a list of established usability heuristics. Expert evaluation is similar, but does not use specific heuristics.

Usually two to three analysts evaluate the system with reference to established guidelines or principles, noting down their observations and often ranking them in order of severity. The analysts are usually experts in human factors or HCI, but others, less experienced have also been shown to report valid problems.

A heuristic or expert evaluation can be conducted at various stages of the development lifecycle, although it is preferable to have already performed some form of context analysis to help the experts focus on the circumstances of actual or intended product usage.

Benefits

The method provides quick and relatively cheap feedback to designers. The results generate good ideas for improving the user interface. The development team will also receive a good estimate of how much the user interface can be improved.

There is a general acceptance that the design feedback provided by the method is valid and useful. It can also be obtained early on in the design process, whilst checking conformity to established guidelines helps to promote compatibility with similar systems.

It is beneficial to carry out a heuristic evaluation on early prototypes before actual users are brought in to help with further testing.

Usability problems found are normally restricted to aspects of the interface that are reasonably easy to demonstrate: use of colours, lay-out and information structuring, consistency of the terminology, consistency of the interaction mechanisms. It is generally agreed that problems found by inspection methods and by performance measures overlap to some degree, although both approaches will find problems not found by the other.

The method can seem overly critical as designers may only get feedback on the problematic aspects of the interface as the method is normally not used for the identification of the 'good' aspects.

Method

This method is to identify usability problems based on established human factors principles. The method will provide recommendations for design improvements. However, as the method relies on experts, the output will naturally emphasise interface functionality and design rather than the properties of the interaction between an actual user and the product.

Planning

The panel of experts must be established in good time for the evaluation. The material and the equipment for the demonstration should also be in place. All analysts need to have sufficient time to become familiar with the product in question along with intended task scenarios. They should operate by an agreed set of evaluative criteria.

Running

The experts should be aware of any relevant contextual information relating to the intended user group, tasks and usage of the product. A heuristics briefing can be held to ensure agreement on a relevant set of criteria for the evaluation although this might be omitted if the experts are familiar with the method and operate by a known set of criteria.

The experts then work with the system preferably using mock tasks and record their observations as a list of problems. If two or more experts are assessing the system, they should not communicate with one another until the assessment is complete. After the assessment period, the analysts can collate the problem lists and the individual items can be rated for severity and/or safety criticality.

Usability 52 of 58

Reporting

A list of identified problems, which may be prioritised with regard to severity and/or safety criticality is produced.

In terms of summative output the number of found problems, the estimated proportion of found problems compared to the theoretical total, and the estimated number of new problems expected to be found by including a specified number of new experts in the evaluation can also be provided.

A report detailing the identified problems is written and fed back to the development team. The report should clearly define the ranking scheme used if the problem lists have been prioritised.

Usability Testing - Critical Incident Technique

Critical Incident Technique Analysis Summary

End users are asked to identify specific incidents which they experienced personally and which had an important effect on the final outcome. The emphasis is on incidents rather than vague opinions. The context of the incident may also be elicited. Data from many users is collected and analysed.

Benefits

The CIT is an open-ended retrospective method of finding out what users feel are the critical features of the software being evaluated. It is more flexible than a questionnaire or survey and is recommended in situations where the only alternative is to develop a questionnaire or survey from the start. It focuses on user behaviour, so it can be used in situations where video recording is not practicable so long as the inherent bias of retrospective judgement is understood.

Method

The CIT is a method for getting a subjective report while minimising interference from stereotypical reactions or received opinions. The user is asked to focus on one or more critical incidents which they experienced personally in the field of activity being analysed. A critical incident is defined as one which had an important effect on the final outcome. Critical incidents can only be recognised retrospectively.

CIT analysis uses a method known as Content Analysis in order to summarise the experiences of many users or many experiences of the same user.

What do you test

Define the activity you intend to study, and get access to the users as soon as possible after the activity has finished. In the case of a lab study this should be after the testing has finished but before any de-briefing takes place; in the case of a naturalistic study, this should be soon after the user has used the software being surveyed or investigated, and if possible in the same environment.

How do you test it

You can do CIT by either employing an interview or by getting the users to fill out a paper form. The user is requested to follow the three stages described below in that order:

Focus on an incident which had a strong positive influence on the result of the interaction and describe the incident

Describe what led up to the incident Describe how the incident helped the successful completion of the interaction

It is usual to request two or maybe three such incidents, but one at least should be elicited. When this has been done, the procedure is repeated but now the user is asked to focus on incidents which had a strong negative influence on the result of the interaction and to follow the above formula to place the incidents in context. There will be some variation in the number of positive and negative incidents users respond with.

It is usual to start with a positive incident in order to set a constructive tone with the user.

Usability 53 of 58

If context is well understood, or time is short, the method may be stripped down and the user simply required to do the first part only: focus on describing the positive and negative critical incidents.

In an interview situation the user can be corrected if they attempt to reply with generalities, not tying themselves to a specific incident. This is more difficult to control if you are employing a written form, so ensure that the introductory instructions are clear.

Analysis and Reporting

When you have gathered a sufficient quantity of data you should be able to categorise the incidents and produce a relative importance weighting for each - some incidents will happen frequently and some less frequently.

For a summative evaluation, you should collect enough critical incidents which will enable you to make statements such as "x percent of the users found feature y in context z was helpful/ unhelpful."

For a formative evaluation, you should collect enough contextual data around each incident so that the designers can place the critical incidents in scenarios or use cases

UI SpecificationsTable of Contents

1 Purpose of the Document 2 UI Design Introduction2.1 Consistency 2.2 Accessibility (A11Y) 3 Developing the UI3.1 Top Level Panel 3.2 Component Hierarchy 3.3 Proper Components 3.4 Layout 3.5 Visual Properties 3.6 Texts 3.7 Keyboard Navigation 3.8 Accessibility 3.9 Windows and Dialogs 4 Links

1 Purpose of the Document

This document provides basic information how to develop user interface of NetBeans with or without help of NetBeans itself. It gives introduction to the rules of consistent and accessible UI, presents useful tips how to use Swing and NetBeans to create UI according the rules, and links more descriptive documents to answer your detailed questions.

2 UI Design Introduction

Before reading how to implement the NetBeans UI, it is good to get familiar with terms and standards used in the NetBeans UI design. This sections tells a few words about it.

2.1 Consistency

User interface of NetBeans should be compliant with Java Look and Feel Design Guidelines (JLF). If you are not familiar with basics of JLF read NetBeans UI Style Guideline, which is extract of the JLF document describing essential JLF standards important for designing and developing NetBeans UI. A design of each NetBeans dialog or window should follow those guidelines.

Usability 54 of 58

Most important attributes of user interface that should be addressed during ui development: Layout - spacing, resizing Keyboard navigation - tab order, mnemonics, shortcuts, default button Text - titles, labels, text areas, tooltips

Once a design or implementation is ready, you should go through the NetBeans UI Checklist document, which contains all of the principles with simple guidance, and should be used to check compliance of the design or implementation with the JLF.

2.2 Accessibility (A11Y)

The point of complete accessible Netbeans is to keep the conditions, which have been set in Section 508 of the Federal Rehabilitation Act. The Java[tm] Accessibility API (JAAPI) is a standard extension in all releases of the Java[tm] 2 platform. A component can utilize this extension simply by implementing the Accessible interface, which consists of exactly one method call, getAccessibleContext(). This call returns an instance of AccessibleContext that is specific to the component and provides the information and functionality necessary to enable its accessibility.

There are elementary steps for accessibility in Netbeans: Each component should provide Accessible Names and Descriptions Do not customize fonts or colors unnecessarily Implement necessary custom colors and fonts via properties Use dynamic GUI layout All interface components must be keyboard traversable Use mnemonics and accelerators Custom components must implement Accessible

If you couldn't decide if something breaks accessibility or not, check this Netbeans Accessibility FAQ please.

 

3 Developing the UI

Lets assume you have a design of a window UI, which follows JLF guidelines and you want to implement it. The window can be a Dialog Box, Alert Box, Wizard, or View. In each case you should start with creating a top level panel which will be used with NetBeans API to create an appropriate window.

3.1 Top Level Panel

The top level panel is a panel which passed with buttons to NetBeans framework creates appropriate window. It is a panel without a command button row, and in case of a wizard also without a wizard graphics. It is recommended to use the NetBeans form editor for developing the top-level panel, even though not the all source code is possible to generate by modifying the component properties. You will occasionally need to add some pre or post initialization code (e.g. mnemonics).

3.2 Component Hierarchy

Top level panel should be implemented as a JPanel using NetBeans form editor if possible. All components should be added directly to this panel to keep the hierarchy narrow and easily maintainable. Never nest a panels just for the layout purpose. Always use the gridbag layout if the design is too complicated to make it in one panel with simple layout manager. However, in some situation there is a need to insert an additional panel to the hierarchy, for example group of buttons (toggle, radio) should be added into separate panel due to accessibility. But before adding the components a design suitable components have to be selected.

3.3 Proper Components

The next step after creating the top level panel is choosing individual components according to the elements used in the design (fields, labels,...). Usually selecting a swing component is straightforward, however it is recommended to use special NetBeans components in a certain cases. Currently NetBeans provides four components that should be used in favor of the Swing:

Usability 55 of 58

NetBeans Components

PropertyPanel is a visual component for setting nodes/beans property values. ListView contains JList based list displaying a direct children of given node. TreeView contains JTree based tree displaying the whole hierarchy of supplied parent node. TreeTableView contains JTable based tree table used for displaying hierarchy of nodes and their

selected properties. The properties are editable. ListView, TreeView, TreeTableView are JScrollPanes thus add them directly to a panel, do not

insert them in another scroll pane.

Wrapped label

Sometimes the design contains a few lines long descriptive text. It has a look of JLabel, but JLabel is not able to wrap the text. This is usually solved by using JTextArea and setting its properties to look like JLabel. Use the following code example:

JTextArea jTextArea = new JTextArea(); // Set JTextArea to look like JLabel jTextArea.setWrapStyleWord(true); jTextArea.setLineWrap(true); jTextArea.setEnabled(false); jTextArea.setEditable(false); jTextArea.setOpaque(false); jTextArea.setFont(javax.swing.UIManager.getFont("Label.font")); jTextArea.setBackground(UIManager.getColor("Label.background")); jTextArea.setDisabledTextColor(UIManager.getColor("Label.foreground"));

If you choose appropriate components, insert them into an empty panel and add all button groups into special panels. Set up an appropriate layout for each panel after then.

3.4 Layout

You can use any swing layout for the top level panel and also other panels, but as mentioned above, avoid unnecessary nesting of panels. The best way is to use the gridbag layout and the gridbag layout customizer in the NetBeans form editor.

After setting the layout, arrange components according to the design. Then customize the layout insets until the spacing corresponds to the design.

Resizing

Check the resizing of the panel. The panel's layout may look correct when displayed, but after changing size of the panel, the layout of components can mess up. If none of components should stretch and shrink according to a panel size, it is important to verify how components move when the user resizes the panel.

3.5 Component Visual Properties

Modifying visual properties (e.g. font, color) of components should be an exception. If the design insists on non-default look of components then new values should be derived from the defaults. This way, if the user changes the defaults, non-default values change accordingly. If JTextArea is used instead of JLabel (see above), the properties should be taken from JLabel defaults too. In this step, set visual properties to non-default values. Tune them until the panel conforms to the design.

3.6 Texts

All text values must be taken from properties files. Otherwise it is not possible to localize them. Preferred way is to use NetBeans API for obtaining string from bundles. If using the NetBeans form editor, you should use the string property editor to set value of each string property. The string property editor generates the NetBeans APIs code for you. Code example:

JLabel jLabel = new JLabel(); // Get text from properties file resized in the same package as Foo // class and set it to the jLabel. The string value key is Foo_message.

Usability 56 of 58

jLabel.setText(NbBundle.getMessage(Foo.class, "Foo_theMessage");

3.7 Keyboard navigation

Important part of the panel design is keyboard navigation. It includes traversal between components using Tab key, and mnemonic assignment to a buttons and labels.

Tab traversal

Make sure that correct component is focused when the panel is displayed and all components are focusable using the Tab key. To change the first focused component in JDK 1.3.* override requestDefaultFocus() method in the top level panel like this:

/* Override method in the top level panel. */ public requestDefaultFocus() { // jTextField is the component that should be focused first. jTextField.requestDefaultFocus(); } To change focus traversal order in JDK 1.3.*, set next focusable component for each component that should get a focus. An example: // jButton should get the focus from the jTextField jTextField.setNextFocusableComponent(jButton);

Mnemonics

Remember that mnemonic characters have to be obtained from bundles as they are part of localization. Also note that it is not possible to use the form editor for setting the mnemonics, so it needs to be coded by hand. Example of obtaining and setting the mnemonic key: JLabel jLabel = new JLabel(); jLabel.setLabelFor(jTextField); jLabel.setDisplayedMnemonic(NbBundle.getMessage(Foo.class, "Label_Mnem").charAt(0);

JButton jbutton = new JButton(); jButton.setMnemonic(NbBundle.getMessage(Foo.class, "Button_Mnem").charAt(0);

3.8 Accessibility

All part of IDE should comply with Accessibility. Most important is to provide AccessibleName and Accessible Description by each component and by dialog. This could be set in Component Inspector

(Properties - Accessibility TAB) or you could use getAccessibleContext().getAccessibleName() and getAccessibleContext().getAccessibleDescription() methods.

AccessibilityName is set up automatic by component's Variable Name in most cases. For JTextFields is Accessibility Name set when setLabelFor is used by any JLabel linked with this TextField. During all developing process of dialog is recomended to use this test tool for accessibility. Follows typical usage, when new dialog is created.

There is necessary use import org.openide.util.NbBundle; on the start of code. Then user could set AccessibleName and Accessible Description like this:

AccessibleContext context = firstComponent.getAccessibleContext(); context.setAccessibleName(NbBundle.getMessage(currentClass.class, "ACSN_stringOfNameForFirstComponent"));context.setAccessibleDescription(NbBundle.getMessage(currentClass.class, "ACSD_stringOfDescriptionForFirstComponent"));context.setAccessibleDescription(bundle.getString("ACSD_stringOfDescription"));

Usability 57 of 58

context = NextComponent.getAccessibleContext();...You see that strings for names and descriptions have ACSN_ and ACSD_ prefixes on the start. Use this convention too please.Each dialog should contain AccessibleDescription as well. To achieve this is necessary to set AccessibleDescription to main panel of dialog, which is forwarded to DialogDescriptor. ...mainPanelOfDialog.getAccessibleContext().setAccessibleDescription(NbBundle.getMessage(currentClass.class, "ACSD_descriptionForDialog"));...For more information look at this more concrete Accessibility Checklist.

3.9 Windows and Dialogs

Each window (view, dialog box, alert box, wizard) should be created using NetBeans APIs. Once you have a top level panel prepared (or in case of the wizard a set of panels), it is easy to create a dialog with correct outside border, title, and command row buttons also correctly spaced.

Use CasesA use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system (UML 1999, pp. 2.113- 2.123). An actor may be a class of users, roles users can play, or other systems. Cockburn (1997) distinguishes between primary and secondary actors. A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance.

A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal. It also includes possible variants of this sequence, e.g., alternative sequences that may also satisfy the goal, as well as sequences that may lead to failure to complete the service because of exceptional behavior, error handling, etc. The system is treated as a "black box", and the interactions with system, including system responses, are as perceived from outside the system.

Thus, use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.

Generally, use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain. This is engaging for users who can easily follow and validate the use cases, and the accessibility encourages users to be actively involved in defining the requirements.

Usability 58 of 58