Create A Website Ethiopia

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.
 

Report This Post