Create A Website Ethiopia

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.

Report This Post