Create a Website Ethiopia

Consider this scenario: you’ve just opened up your browser and you hope to send some flowers to you mom for Mother’s Day. Where do you begin?

You might just guess and type in flowers.com, hoping to find a flower site. Maybe you already known a popular flower service, and type in its URL. Perhaps you go to a search engine and type “mother’s day flowers.”

You might use a bookmark or go to a friend’s hotlist. While it seems there are a lot of possibilities, the common approaches are relatively few and can be enumerated and analyzed.

So now you’ve come to a flowers web site. What next? You need to find some Mother’s Day flower options.

You look around the screen for something that suggests Mother’s Day or something that suggests viewing flowers; on many sites, you may just look for a generic “Products” or “Buy stuff” link.

A basic information analysis can explain much of what happens in this scenario: at each point, users look for anything on the screen that provides a cue to where they are and how they can get closer to their goal.

Navigation Style Depends On Task
People determine the way they’ll navigate by what they’re trying to accomplish. In information-seeking activities, users want to find something, so they directly follow links until they find it.

However, when they don’t have a clear idea of what they’re looking for, they tend to explore more. When users are trying to study a topic, perhaps taking a linear path through a site and making sure they read every page.

When they’re simply trying to understand what a site is about, they may sample a lot of pages but spend little time on each one. As we discuss how people navigate, we’ll ground each idea in a certain type of task, but the specifics will vary based on the type of task.

Models of Human Navigation
If users were omniscient, they would know the entire structure of your site and would follow the shortest, simplest path to their goal. This optimal path forms a good point of comparison when evaluating how well your users are actually doing.

A slightly more realistic model of how people navigate is the optimal rationality model. In this approach, users determine the probability that each link goes to their destination and then follow the highest-probability path, remembering everything they see and backtracking as soon as a trail they left behind has a higher probability of taking them to their goal than the trail they’re on.

They estimate the probability based on the information scent in the link label (see sidebar “Information Scent”).

If you watch people navigate, you will sometimes see behavior that looks similar to this approach, but you’re likely to see people forget alternatives and persevere on unpromising paths.

A more realistic view is a satisficing model. Satisficing is an approach that emphasizes that people tend to behave in a way that minimizes mental effort.

They remember as little as needed and avoid complicated planning. Describes how someone would look for information from a satisificing approach.

As they browse, at each page they make their best decision based on the information available on that page. A typical user goal might be “I want to find a specific piece of information.”

The first step the user might take is to visit a page. Then the user would follow the visual hierarchy of the page to identify where to start. If it’s a content page and it has what the user is looking for, then the task is done.

If it’s a routing page or the content is not relevant or sufficient, the user will scan the options. In a given navbar, he or she will scan the links from top to bottom or from bottom to top. From here there are two options.

The first is to find the first good match (especially in long lists). For here there are two options. The first is to find the first good match (especially in long lists). For each link, the user will evaluate the likelihood that it contains the target content.

If it does, the user will follow it, without reading the remainder of the list. In the second option, the user finds the best match (especially in short lists) by scanning all links and following the link to the best match.

This model of navigation has some immediate implications for how you design your site. It suggests that the page title and a brief summary of the page content be immediately visible, and important navigation elements should be visually salient in a quick scan of the page.

It also suggests that frequently used links should be toward the top or bottom of lists, and that link labels need to be useful cues to the information they lead to.

People may also navigate using mental maps. A mental map is an idea the user has of how the overall web site is structured.

Using this concept of the site organization, users select the route that seems most efficient, even if the individual link they follow suggests nothing in particular about their goal.

We help provide people with mental maps by the way we present the navigation bar or the way we organize the pages in a site map.

People are more likely to navigate by thinking in terms of a mental map when the site provides a very strong model for its organization, such as well-known sequences (e.g., “page 2 of 10”), familiar physical spaces (e.g., maps), or well-known taxonomies (e.g., Animal – Mammal – Canine – Dog).

For sites that people use frequently, especially complex ones with no clear mental map, they may become experienced enough to navigate through rote memorization. That is, when they recognize a familiar path, they simply follow the same path they’ve successfully used before.

You’ll often see users follow the same inefficient path because they know the way. In such cases, they may rely on landmarks, and orientation cues to confirm they’re in the right place, and page variation can help people recognize their unique location (whereas most other design principles encourage consistency and uniformity).

Another view of user navigation behavior is known as information foraging. This approach suggests a comparison of people’s information-seeking behavior to animals foraging for food.

Think of people as consuming local information resources before they stray to other areas for more information. In other words, the cost of getting every last scrap from where you are is less than the cost and risk of seeking additional sources elsewhere, at least up to a point.

Thus, we find people lingering on the first site they find rather than pursuing other sites that may be more useful, because if they abandon the site, they risk wasting their time when they fail to find more promising information elsewhere.

The information foraging model also stresses that people modify their goals as they get additional information that might suggest they reframe their questions.

The most general approach that combines the previous models is the information costs approach.

This approach says that users choose among strategies based on effort versus payoff: that is, the cost in mental effort and time leads to a tradeoff among planning, sense-making, scanning navigation options, and clicking.

This approach suggests that if you want the user to get somewhere, you should lower the cost of all these activities.

The information costs approach differs from the optimal rationality approach in that the latter ignores people’s psychological limitations, whereas the former factors in psychological costs in choosing the best course of action.

In the most general perspective of developing an optimal navigation structure, you should factor in the cost of not finding the information and the costs to you (as the designer) of organizing and maintaining the information.

Designing systems that are tolerant of human error becomes crucial when any task has potentially dangerous and costly consequences, or when the outcome is not easily reversible.

Financial and medical web applications are prime examples of sites where reducing human error is especially important. A central theme in designing for human error is to build a multilayered defense.

Designing for human error effectively requires addressing several aspects of error management, including the following.

Prevention: Eliminate the potential for error to occur by changing key features of the task or interface. This is always the preferred method for error management and also the most effective.

Reduction: Reduce the likelihood that the user will get into an error state when prevention is not possible by ensuring the user is aware of action consequences and by training users on both normal and error-recovery procedures.

Detection and identification: Ensure that if the user does err, the system makes it easy for the user to detect and identify the error.

Recovery: Following error detection and identification, ensure that the system facilitates rapid correction, task resumption, and movement to a stable system state.

Mitigation: Minimize the damage or consequences of errors if they cannot be recovered from.

Even when all other error management steps have been taken, errors will still be made, so systems should be designed such that catastrophic outcomes from human error are not possible.

Example: Error Recovery
The issues for error recovery are detection, identification, correction, and resumption. For the user the questions are simple: What happened? What do I do now?

Electronic commerce is a prime domain for error-recovery design flaws that can adversely affect usability. Consider, for example, the order form in (slightly modified from www.netopia.com).

Here, the form indicates that certain asterisked fields are required. The credit card selection menu is not indicated as a required field and is easy to miss (the card type is not really necessary and can be derived from the card number).

Also note the instructions at the bottom of the form telling the user not to use the Stop or Back buttons. These instructions help prevent users from accidentally performing multiple transactions or from mistakenly believing that a transaction was canceled when it was not.

The problem is that this error management measure hinders recovery from other error types. If the user forgets to select the credit card type from the pull-down menu, the commerce server indicates an error by displaying the screen shown in.

The user detects that an error has occurred from the message heading. The system even identifies the error as an invalid entry in “WXK_PAYMETH” field.

Unfortunately, that field name is only clear to the system and its programmers. Most users would not know from this that the problem is an incorrect entry for the payment method.

In fact, the credit card menu is not strictly a field and does not really reflect an entry as the message suggests.

This would likely cause more confusion. Even if the error is deduced by the user, correction is hundred by the message on the original order form that said, “Do not use the STOP or BACK button.” There is no other navigation on the error page, so using the Back button is, in fact, the only option.

A better way to handle incorrect data entries is to return the user to a facsimile of the order form, with the missing or erroneous data fields highlighted in red (or indicated in some other salient way).

Examples of correct entries can also be helpful. Minimally, error pages should identify errors in a way that users can understand and provide clear recovery paths when possible.
Simple, practical techniques, applied consistently, can dramatically improve the web site development process. More significantly, these fundamental task analysis methodologies please the ultimate critic: the user.
 

The goal of a task analysis is to improve the user’s performance, productivity, and, ultimately, his or her experience.

Used in conjunction with other design techniques, task analysis can be a very powerful tool that can improve procedure consistency and clarity, reduce task execution and learning time, and reduce the number and types of errors that can occur.

Consistency
Interface consistency means that a system behaves in ways users expect. It means that users can transfer the knowledge they gained in some previous experience to the current situation, and that their prior experience will in some way enhance their current performance.

That is, if users have already learned one method for doing something, their performance will be better if they don’t have to learn another means for doing the same thing with your system.

For example, nonstandard use of blue or underlined text that is not a link often confuses users and results in increased errors and slower performance time.

Consistency also applies to the design of procedures. Although there are times when consistency itself can be confusing, such as when users mistake one procedures for another, it is generally a good idea to make procedures as consistent as possible.

An example of inconsistent procedures can be seen in JC Penney web site shown in. Here there are two paths by which a person can purchase the sweater featured on the home page.

By clicking on the thumbnail image, the user is presented with the screen shown in. There is a numbered sequence of steps that leads the user through selecting size, color, and quantity.

If instead, the user enters the catalog number for the sweater in the field at the top of, the user is presented with a different method for selecting the desired sweater. In this case, all of the colors and sizes are listed in single pull-down menu at the bottom of the page.

Both procedures seem to be adequate for selecting a sweater, but why are they different? At first glance it might seem that the designers went to extra effort just to make the procedures inconsistent.

In reality, there is probably a technological or business-related reason for it: perhaps the two business functions of selling catalog items via the Internet and selling promotional items on the company web site were designed by different development teams. But users don’t care why.

It may not even bother users enough that they would consciously notice that the procedures were different. But it might add a few extra seconds of confusion, and it might make users misremember where they bought a previous item if the procedure is not the same.

Furthermore, it might leave them with a felling that things just aren’t right. In general, you should strive to be consistent unless there is a good reason not to be. Technological issues alone should not dictate your users’ experience.

Brevity and Clarity
Task analysis can also help to clarify and shorten your procedures. What may seem like an acceptable process for users to perform can sometimes prove much more convoluted when seen on paper.

Task analysis makes your user interface procedures visible, showing both their good and bas aspects.

It is the best way to find problems prior to user testing. There are two rules of thumb when considering procedure clarity.

First, procedures should be relatively short, no more than 15 to 20 steps, although 10 to 15 is better. People have trouble with long procedures unless there are memory aids provided on paper or by the system.

The second rule of thumb is that if a procedure is difficult to describe on paper, it is probably difficult for users to perform.

Combined Functionality and Fewer Server Requests
Another goal of task analysis should be to combine functionality when possible. Each screen a user must view probably adds at least 30 seconds to a procedure (very complex pages can add significantly more time).

Combining functionality means minimizing the amount of effort users must exert to accomplish the same goal, commonly by minimizing the screens users must navigate. A task analysis can be used to determine where such combined functionality might make sense.

For instance, when the analysis shows that users do the same task multiple times, it might make sense to allow them to make multiple entries at the same time.

The catalog ordering system seen at the JC Penney web site is an example of where such combined functionality might be useful.

The site is designed to allow customers to order only one item at a time. However, the paper catalog on which the web site was based contains an order form that allows multiple items to be ordered at once.

This encourages customers to purchase multiple items per order. Since the web site design doesn’t duplicate the functionality of the old paper-based system, ordering multiple items online is painfully slow.

Purchasing multiple items per visit it therefore discouraged by the design. When designing technological replacements for manual systems, the new process should always be at least as good as the old process.

Example: Inefficient Tasks
Another suitable occasion to combine functionality is where little new information is given on a new screen. For example, a pattern that has emerged in some web applications, especially those driven by database requests, is that of Search-List Detail. Search denotes the screen on which some database query is generated.

List is the set of items returned by the search, and Detail is the item from the list that contains the necessary information for the task. This pattern is common because development tools support it easily.

However, it sometimes results in tasks with extraneous and nonfunctional steps that the user must perform. In many cases, screens can be combined to reduce number of server requests, the number of screens, and, as a result, the overall task time.

Consider, for example, the train schedule show in (www.amtrak.com). It shows the normal schedule for all trains from Chicago to Ann Arbor. To find the current status of a particular train, the user must select that train by clicking on a radio button, and then pressing the Show Train Status button.

This would eliminate the need for the Show Train Status button and save the user a couple of actions. A more fundamental change could be made by adding the status information to the Schedule page.

This would eliminate both the selection actions and the need to load another page. Such systems are often designed in this way because the information sources are held in different databases (and possibly in different physical locations).

To simplify the database queries for the web-application programmers, only one query is made per page. However, this type of technology-driven design is often inconvenient for the end user.
 

We favor a hybrid approach to task analysis that analysis that combines both the high-level interactions of users other actors with depth and psychological grounding of hierarchical procedure decomposition.

The general steps are (1) start with use cases, (2) decompose tasks hierarchically, and (3) determine appropriate technologies.

Start with Use Cases
Determine the actors by asking who will be using the system and what parts of the system they will be interacting with.

For example, in a simple business-to-business commerce web site, actors might include a set of office personnel from each department responsible for keeping office supplies in stock.

Also from the customer’s company, purchasing agents might need to negotiate prices and confirm orders over a certain dollar value.

Users from accounts payable would need to review monthly bills from the seller and issue checks.

Actors from the seller’s side might include customer account representatives who would need to see customer buying patterns, credit representatives who would need to approve high-value orders, and shipping agents who would handle customer deliveries.

Next, build user profiles by determining the background of the users, their knowledge, skill level, motivation, and any other relevant background information.

Obviously the backgrounds of the actors described will vary greatly from financial experts to office administrative staff to delivery staff. Their possible motivations will be likewise varied.

For instance, the motivation of the office staff might be to make sure no one in their department runs out of essential supplies. Users from the purchasing department, on the other hand, might be tasked with ensuring that departments don’t go over budget.

The seller’s account representatives would be motivated by sales amounts and would instead try to maximize sales.

The next step is to develop typical scenarios by asking. What are the user’s goals? What are the typical things they will try to accomplish?

Do this for each user group identified. For instance, one scenario for the customer’s office staff might describe placing a regular monthly order for pens, paper, and printer cartridges.

Another scenario might describe someone from the customer’s company purchasing a special onetime item like a microwave oven.

From your scenarios and user profiles, determine the necessary functionality by asking what additional functionality the system must provide to support the users.

In the first example scenario just described, the customer needs a way to see the previous months order the office supplies and modify if for the current month.

Upon placing the order, the customer would need to complete the transaction and verify any billing information required.

In the second example, the customer would need means for quickly performing a keyword search from an online catalog, comparing costs and features for all of the microwaves sold, and seeing which models were available. As in the first case, the users in this example would also need to complete the transaction.

Finally, you need to organize the scenarios. Based on common functionality within user groups, what are the high-level tasks?

In both of the examples given, the users needed to place orders, confirm transactions, and verify billing information. Although not specified, they also probably needed to log in at the beginning and obtain written confirmation at the end.

Each of these subgoals requires a specific task procedure that will allow users to accomplish their goals and complete their tasks.

Decomposes Tasks Hierarchically
In this phase, your first task is to prioritize and determine the frequency of tasks. Start with high-priority, high-frequency tasks. After looking at all of the scenarios for all of the actors, the designer in our example might determine that the monthly purchase task would occur with the highest frequency and would be classified as such.

Given the importance of the task – the dollar value of the combined instances in any given month and the potential cost of making mistakes within an entire month’s purchases – it might also be classified as high priority, perhaps warranting additional analysis and testing.

Next, decompose the high-level tasks down to page-or mid-level procedures. For example, the monthly purchase task might be decomposed into the following subtasks:

(1) log in, (2) view previous month’s order, (3) modify previous order with current needs. (4) confirm order, and (5) get receipt.

Evaluate at each level of decomposition and repeat the process is necessary. For example, if we saw that several of the high-frequency tasks also included the login task, we would know that logging in was a high-frequency subtask that warranted additional optimization.

If it was also known that users operated from secure computers, some or all of the login information could be stored on their computers. This would allow the login procedure to be simplified by requiring the user to enter less information during login.

Determine Appropriate Technologies
This phase begins with mapping out server requests and data flow. For example, the monthly purchase task might translate to these steps:

(1) Get customer ID from login
(2) Determine the department
(3) Access the account
(4) Get the previous month’s purchase
(5) Look up item descriptions from item numbers on the purchase
(6) Generate a new order form
(7) Format and display for the customer

Next, create low-level, generic system procedures. For instance, looking up item descriptions could become a generic, building-block procedure that could be used in the monthly purchase task, and any other task that required the information.

Finally, map these into the application level. Combinations of system procedures can then be formed into application-level user tasks. For example, getting the customer ID, department, and account information could be combined into an Account view for the customer.

Applying hierarchical task analysis to web site design is a direct and systematic approach to characterizing the knowledge required by a typical person to use your site.

As the name implies, it involves organizing the tasks in a hierarchy and decomposing the procedures to an adequate level. The process of decomposing the user’s tasks is iterative and involves the following steps:

1. Identify the primary user goals.
2. List the steps that a user must perform to accomplish the goals.
3. Optimize the procedure.

After the task is described at a sufficient level of detail, the procedures can then be optimized to minimize the number of steps, improve consistency among similar procedures, reduce user error, or make any other adjustments that may be critical to your site’s goals.

Often, as a procedure is listed, it will be revealed that the steps to accomplish a goal are actually a collection of other, smaller subgoals. For instance, filling out a form involves filling out a series of text fields, radio buttons, checkboxes, and so forth.

Instead of listing out each individual action for each form element, we can just say “Complete the address text field” or “Select a country from the pop-up menu.”

Each of those steps is actually a low-level interface goal involving a number of user actions. For example, to accomplish the goal “Select a country from the pop-up menu,” the user must
1. Locate the pop-up menu named “Country.”
2. Move the cursor to the menu.
3. Press the mouse button.
4. Locate the appropriate country from the list.
5. Move the cursor to the country name.
6. Press the mouse button.

This type of generic procedure may be used many times in an interface by just changing the name of the menu and the menu item to be selected. Do we need to list this out every time?

No, it is only necessary to specify it once, knowing that it is simply a generic procedure, much like a computer program. Change the input data (e.g., the menu name) and the same procedure can apply anywhere there is a pop-up menu.

Furthermore, there is an additional incentive to optimize such routines, because if you optimize one generic routine, the benefits are seen every time the routine is used, potentially a much greater payoff than optimizing a procedure that is only used once.
How Far Down Should You Decompose a Procedure?

Tasks should only be decomposed to a granularity that you have any control over or that will affect your decisions on interface design choices.

The point is that task decomposition should only be done as long as there is a potential gain from the analysis.

For example, it may not be necessary to list out the steps to select an item from a pop-up menu because there may be nothing you can do to change it.

If the system dictates that only a limited set of interface elements can be used, then a deeper analysis is pointless. However, if you need to choose between two interface elements that can produce the same result, it may be useful t use what is required from the user’s point of view.

A typical stopping point for decomposition is the level of observable user actions, such as keystrokes and mouse movements. However, designers should not neglect the mental effort that users must exert while performing a task.

For example, each new screen presented to the user will require at least several seconds to understand (i.e., time to establish a gestalt).

It is also important to consider items that users must remember between screens and complex decisions that users must make, as these are a prime source for errors.

For guidelines on how to assess the mental actions that users must perform during a task, see Kieras’s “A Guide to GOMS Model Usability Evaluation Using NGOMSI.” (1997) or Raskin’s The Humane Interface (2000).

A good benchmark for determining an appropriate stopping point is whether a person can perform the task properly using your procedures.

The task procedures should be general enough to apply to any set of input data, but include enough specific information that a person could perform the task. For more information on this type of task analysis, see the “GOMS Analysis” sidebar.

Hierarchical task analysis is a means of systematically defining a task from the user’s perspective. We can look at task procedures on three levels: user level, platform level, and application level.

User-Level Goals and Procedures
At the top level, task procedures are generic descriptions of the goals users will accomplish, like buying a book.

These descriptions can be viewed as generic because we can accomplish the goal of buying a book through many means, both electronic and physical.

Platform-Level Goals and Procedures
At the bottom level, task procedures are those imposed by the interface. If we are buying books online, we will probably be using a web browser and will be utilizing common web browser interaction techniques such as pointing, clicking and using pull-down menus and text-edit fields.

Alternatively, if we are buying our book from the local bookstore, we will probably employ different interaction techniques, which might include driving a car, searching bookshelves, and completing a transaction with a clerk. This level is also generic in that many different high-level goals can be accomplished using various combinations of low-level procedures.

Application-Level Goals and Procedures
In between the high and low levels, task procedure at the middle level specify how users will accomplish their top-level goals using the low-level interface procedures required by your system’s platform.

This is the level where, as designers, we can often have the greatest impact. High-level goals are driven by user needs and marketing decisions that are often a fixed requirement given to the design team.

Likewise, low-level procedures are often determined by the underlying hardware and software, and also cannot be changed. What we can easily change is how the low-level procedures are used to accomplish the higher-level goals.

We can affect how many and what kind of steps the users must perform. We can determine what information is shown on their screens, and we can determine how many and what kind of steps the users must perform.

We can determine what information is shown on their screens, and we can determine how many pages they have to navigate.

This is true of noncomputer interaction as well. For instance, we could change the procedure by which customers bought books in our bookstore example by having employees personally find books for customers and suggest related books for them.

This would minimize the time customers spend searching for books, but doing this for every customer would be very expensive and might have undesired side effects like reducing impulse buying.

Understanding the tasks and their context
The bigger challenge in performing a task analysis is accurately capturing the essence of the user’s job.

Simply asking users how they do what they do is not enough because users don’t think about the steps they go through. A typical response to “How do you do this?” is “I don’t know.”

I’ve bee doing it this way for 20 years and it’s the only way I know.” Describing procedural knowledge is notoriously difficult for many people. The most direct method is to start by finding any written documentation on how users are supposed to be doing their job, and observing them in action to see how their behavior differs from the “official” instructions.

If no written procedures exist, then analysts must observe users as they perform typical task scenarios.

Formal methods exist for understanding the context of people’s tasks, such as contextual inquiry. For a comprehensive treatment of contextual inquiry and contextual design, see Beyer and Holtzblatt (1997).

Use cases provide a good starting point for organizing this information. For other techniques, see the sidebar “Techniques for Understanding Tasks.”

A potential pitfall when interviewing users is putting too much emphasis on their design suggestions.

Although user participation is critical in the design process, caution should be exercised because users don’t always know how to design what they want or need.

For instance, it is common for some users to assume that an aesthetically pleasing site is more productive. Likewise when considering task performance time, users’ perceptions of their productivity do not always reflect their actual efficiency.

Their opinions about interface quality are always valuable, but they are not always correct.

If we only look at a single web page, the procedures for using it are typically trivial. So why go to the extra of conducting a task analysis?

The answer, of course, is that web sites are not made up of just one page, and the interactions between users and web pages is not necessarily trivial. We need to consider at least three distinct levels when conducting a task analysis.

• We need to look at the big picture. Who are the user groups that will be using the site, and how do they interact with other users f the site in the course of their overall job responsibilities?

• We need to consider the pages that a single user will navigate to accomplish his or her goals.

• We need to address the procedures that a user will utilize within each of the pages.

If we address only one of the levels, we may make the procedures within each of the pages very simple, but might neglect the possibility that some of the pages may be altogether unnecessary.

We may also fail to see additional improvements that could be made to the overall workflow.

One way to specify the necessary information at each of the levels is to combine use case analysis with hierarchical task analysis.

Use cases document the interactions between different user groups and are used as a first pass at high-level design. The following sections describe use cases, hierarchical task analysis, and their combination into a powerful analysis technique.

Use Cases
Use cases were developed by Ivar Jacobson as a way to analyze software development from the perspective of how a user would typically interact with the system.

Use cases combine a simple way of capturing user scenarios (i.e., instances of how a user might perform a procedure) in a text document and diagramming how different user groups interact while using the system.

They start with the users or actors of a system and describe the activities the actors engage in while using the system. Actors can be users, databases, other companies, or anything else that interacts with your system.

A scenario is the set of steps or actions that an actor must accomplish to achieve a particular goal.

Use cases include the typical, or primary, scenario that the user will go through to accomplish a particular goal and can also include a set of alternative scenarios that the use may go through in atypical situations.

Use cases are easy to work with because most of the necessary information for building a system can be specified in a standard format.

The interaction between different actors in a system can then be captured using use case diagrams. Use case diagrams provide a standard means for viewing an entire transaction in a single view.

Although use cases are a very powerful tool for system development, they have some weaknesses in the design of usable systems. For instance, a use case won’t necessarily tell us if a procedure (scenario) is inefficient.

It also won’t tell us whether our procedures are within the possibilities of human performance or how much training would be required for a person to perform them. These weaknesses exist because use cases were developed as a software development tool.

They are not rooted in human psychology, nor are they intended for that purpose. For many projects, such attention to detail may not be necessary.

For mission-critical or safety-critical tasks, ensuring efficient, error-free performance becomes much more important. For these types of tasks, we turn to hierarchical task analysis.
 

Task analysis refers to a family of techniques for describing various aspects of how people work. This can include procedural analysis, job analysis, workflow analysis, and error analysis.

Procedural analysis is a set of techniques to analyze the procedures people perform for an individual task. Job analysis is the set of all tasks a person performs as part o a job or to achieve some overall goals.

Workflow analysis examines the flow of information and control that is necessary to complete a process that may include multiple people and multiple tasks. Error analysis determines where, when, and under what circumstances errors will occur.

The most crucial component of task analysis is gaining a deep understanding of the goals people are trying to achieve.

You can apply various task analytical techniques within your web site development process to clarify and formalize the information from requirements gathering, and to design a process within your web site that allows people to efficiently achieve their goals.

To illustrate how a task analysis might be used, consider the flowchart in which maps out a sequence of screens a user might go through while purchasing a stuffed giraffe. Each thumbnail represents a screen in the buying process.

The arrowed lines connecting the screens on the left represent a normal sequence of events.

For instance, the user starts at the home page, goes to the Products page, goes to the Giraffe page, completes the billing information, verifies that he or she really wants to make the purchase, and receives a confirmation by the system that the stuffed giraffe has been ordered.

The lettered lines on the right side of the figure represent possible optimizations that can be found through a task analysis.

For example, if the task analysis revealed that a significant number of users came to the site to buy giraffes, the company might place a giraffe link on the home page that would take users directly to the Giraffe page (line A).

This could save users a significant amount of time by bypassing the Products page. As indicated by line B, the company could also place a Buy Giraffe button on the home page that would take users directly to the Billing page, bypassing two unnecessary screens.

If the company had customer billing and shipping information stored from a previous visit, it could also bypass the Billing page, saving customers even more time (line C). Likewise, there are other optimizations that could occur within the process, such as placing Buy links on the Products page to bypass individual product page (line D).

In addition, there may be ways to eliminate screens, perhaps by combining the purchase confirmation with another page, thus saving the user even more time and effort.

There are many different optimizations that might be made, and making the process explicit through a task analysis allows designers to make rational choices regarding them.
Task analysis can help improve the consistency and coherence of the procedures required your web site.

Because it makes explicit the procedural knowledge expected from your uses, it also clarifies learning requirements and can provide the basis for training materials.

Furthermore, since the procedures are clearly spelled out, a task analysis can be used to provide a context-based help system for your users.

Task analysis is critical to providing a system that is efficient to use and easy to learn while not exceeding human limitations. In addition, the high-level goals specified in the task analysis make explicit the functionality that you building into the system. Thus, there is little confusion about the intended purpose of the site.

Task analysis is used throughout the design process because it acts as a road map for the entire design team. In each portion of the design, the task analysis is used as a guide to answer the question.

Does this design support the task? For example, an information architecture is only useful if it supports the task. The same goes for writing and graphic design. No stage of design can be done in a vacuum.

Likewise, when performing quality assurance and user testing, the task analysis tells the team what to focus on, how important each element is, and how to determine whether the overall design is successful.

Users need to be considered early and often.  Usability needs to be a part of every step of the design process. 

Our approach is pervasive usability – integrating usability into everything we do.  Our philosophy is that usability should not be and add-on, but that everyday processes should be modified to be user-centered.

Make usability part of everything you do.  Make it a lifestyle. People shouldn’t be an afterthought in design. 

Testing and fixing a web site after it’s built is inefficient and unlikely to produce a good design. 

Information about users should come as early as possible in the design process, and bad designs need to be weeded out long before you’ve overcommitted to them.  Building web sites for people happens from the start.

Our view of how usability must be achieved parallels the modern view of quality assurance. 

A hundred years ago, creating a quality product was achieved by hiring a master craftsman and relying on expertise. 

As more and more production became automated, quality control shifted to a perspective of testing a product to verify its high quality, a procedure that did not required as much expertise. 

But testing is an expensive technique because it can mean that a large number of low-quality products are being produced before being filtered out at the end. 

To achieve quality at a reasonable cost, we need to push quality assurance back to the earliest point in the production process.

Today, total quality management (TQM) programs look at every step of the process to ensure that quality isn’t compromised along the way. 

This is achieved with appropriate planning, process management, documentation, and verification. 

From our perspective, quality assurance is subset of the overall usability goal. After all, a web site isn’t usable if it isn’t working.

Design process is at least as important as design principles.  Planning and method are the only reliable, effective mean to achieving usability within other design constraints.

Highly usable web sites are intuitive. They are transparent. They support the users and allow users to accomplish their goals quickly, efficiently, and easily.

On the other hand, poor usability means that people using your web site cannot efficiently perform the tasks you intended. 

Poor usability can come from overly complex web sites, can lead to large numbers of user errors, or can mean that people just don’t like using your system. 

For instance, one aspect of usability is that users should know what to do next.  They should either be given explicit instructions or the web site should follow some known interaction pattern. 

If the next steps are not obvious, users will spend precious time trying to figure them out.  They may make mistakes or may just leave your web site with a bad feeling.

WHAT IS USABILITY?
Usability is defined as the degree to which people/users can perform a set of required tasks. It is the product of several, sometimes conflicting design goals:

- Functionally correct:  The primary criterion for usability is that the system correctly performs the functions that the user needs.  Software that does not allow users to perform their tasks is not usable.

- Efficient to use:  Efficiency can be a measure of the time or actions required to perform a tasks. In general, procedures that are faster tend to be more efficient.

- Easy to learn:  Ease of learning determines how quickly new users can learn to accurately perform a task procedure. In general, the fewer steps a procedure contains, the easier it is to learn.

- Easy to remember.  The degree to which a system taxes human memory determines how easy it is users to remember. 

Systems that compel users to paste memory aids on their display screens are not easy to remember.

- Error tolerant:  Error tolerance is determined by how well errors are prevented, how easily they are detected and identified when they occur, and how easily they are corrected once they are identified. 

Error tolerant systems can also prevent catastrophic results if all other measures fail.

- Subjectively pleasing:  In the end, usability is often determined by how users feel about using the system. 

Although nonfunctional graphics and other interface elements can skew a user’s perception of usability, user satisfaction is probably a combination of all these criteria.

Because the goals of usability can conflict with one another, the context of the design will determine the priority with which each goal is applied. 

For instance, a kiosk system that assumes no prior training would probably have ease of learning a primary usability goal. 

A safety-critical system, such as a nuclear power plant, would have error tolerance its primary usability goal. 

On the other hand, a video game would have to be fun to use (subjectively pleasing) in order to succeed in the marketplace. 

In addition, video game designers often depend on human error to make their designs more compelling, so conditions for human error are purposely built into games.

Only by attending to the myriad details does usability emerge a dominant property.  To ensure high usability on our own web projects, we defined a development process that incorporates proven techniques from software and usability engineering, graphic design, project management, and other disciplines. 

The process had to be practical and lean.  It had to allow us to work on multiple projects of varying sizes with fixed budgets. 

It had to help us keep track of the details that can kill usability and destroy profitability.  This book is about that process.

WHY IS USABILITY IMPORTANT FOR WEB SITES?
Web browsers have become a de facto standard for interbusiness communication and commerce in the new e-business paradigm. 

We are in the midst of a massive shift from diverse technology structures with business organizations, to a model in which business units have access to the most up-to-date information available, data is only entered once, and changes propagate instantly.

Legacy information systems have been given new life as businesses use the Web to provide stored corporate knowledge to those who need it, both inside and outside an organization. 

Web-based applications have become a standard, cross-platform nonproprietary means for businesses to communicate with each other and with consumers.

Businesses are continuing to increase their productivity, with information technology playing a critical role. 

Increased productivity is belonging an necessary element for achieving or retaining a competitive edge.  It may even be the key to survival for some businesses. 

Nevertheless, we have seen in the past that technology alone cannot achieve increased productivity. 

Actuality, there is ample evidence that technology can decrease productivity if poorly applied. 

High usability is a key factor in achieving maximum return on information technology investments.

WEB USABILITY PROBLEMS
Although the Web is based on a relatively simple interface consisting of links, buttons, menus, text fields, text, and graphics, sever usability problems are common. 

The four broad areas that contribute to these problems:  human perception, navigation, human memory, and database integration. 

We will discuss these areas in detail and provide examples for the types of usability problems they can include.  While there are certainly other areas that can be troublesome, this discussion should provide a convincing argument for, integrating usability into web design.

Human Perception Problems
Perceptual issues can occur when pages are designed according to how the underlying information is physically stored (e.g., in a database), rather than how the information can best meet the needs of the user. 

This strategy may make page delivery and maintenance efficient, but it can also make the user’s task slow and error prone. Other perceptual problems can arise when artistic style is considered before usability. 

Navigation
Navigation disorientation is among the biggest frustrations for web users.  Three common questions users ask themselves while navigating on the Web are:

Where am I now?
How do I get where I want to go? and
Where does this go?
 
To find a navigation path, users must predict what will happen if a particular link is pressed and determine whether it takes them closer to their goal.

Navigation design issues include whether there is a logical architecture to the information in a site, whether there are sufficient indicators to give the user’s current location, and whether the language and the organization of the navigation system match the user’s expectations and needs for the task.

One navigation problem comes from the use of ambiguous links that may cause the user to go to the wrong page. 

Human Memory
There are three primary human memory issues to consider when designing for the Web.  First, if too many items must be remembered, it is likely that something will be forgotten. 

Second, the longer the time frame that items must be remembered, the more likely they are to be forgotten. 

Third, the greater the similarity among the remembered items, the more likely they are to be confused with one another. 

Web sites that required users to remember items from one page to the next are likely to cause problems.

Database Integration
As Web technology has matured, database systems have become a central tool for building web-based software applications. 

Although this approach is very powerful and can easily streamline ongoing system maintenance, issues with integrating database technologies can create severe usability problems for the end user. 

A common problem is that information that the user sees gets out of sync with information in the serving database.