Preparation for a User Day

How Do We Create Tasks?

Whichever type of User Day you select, you must prepare a meaningful set of tasks to be handed out to the test users in printed form. The tasks should consist of a comparable and representative set of realistic scenarios. These scenarios can be derived from existing user roles or user/task analysis.

Choose Realistic Tasks

When choosing and creating the tasks, do not let yourself be distracted by the planned or implemented functionality; i.e. you should not adjust the tasks to the application's strengths and weaknesses. The application must include realistic and common tasks so that users can detect typical problems.

The tasks should correspond to the typical work tasks of the user identified in the user/task analysis. The goals is to test the essential features of the application, not the rare exceptions used by only a few users or tasks that do not correspond to the actual tasks performed by the user.

The tasks should not exclude critical or controversial parts of the application. The tasks should cover those parts of the application that the developers themselves consider to be critical from a design or implementation standpoint. The input from the User Day can be especially helpful in such critical parts of the application.

On the other hand, it is clear that there is no point in testing tasks for which the necessary functionality has not yet been implemented. If you encounter such a "black hole" during exploratory use, you can point out to the user that this part has not yet been implemented or that the user should continue with a paper outline.

Another way of getting a realistic set of tasks is to ask the customer to bring along some of his or her normal daily tasks. Of course, this is easier with a prototype than with a development system that does not contain any customer data.

Create Well Formed Tasks

The problem should begin with a general description of a test scenario:

"Imagine you have started work at Incognito Enterprise, a newly formed Internet company. You are their web server administrator and are responsible for all web servers in the company. There are 15 servers in total, located in 3 buildings..."

The individual tasks should fit within the framework of the overall scenario.

The tasks should be formulated so that the objective of the task, but not the solution, is explained.

Correct: You want to rename cost center 500 from "Auxiliary Personnel" to "Temporary Employees."

Wrong: Select cost center 500 with a mouse click and change the name from "Auxiliary Personnel" to "Temporary Employees" by choosing the option "Rename cost center" from the right mouse menu.

Only a clear description of the task scenario and the objective, and not the instructions on where and how to use the application, should be included.

The task block should begin with a relatively simple task (such as displaying existing data).

It should be possible to solve the tasks independently (for example, even if the first task cannot be solved or is solved incorrectly, it should be possible to solve the subsequent tasks). However, you are permitted and recommended to divide more complex tasks into separate dependent parts A, B, C and so on.

The tasks should be defined in the user's language.

Correct: Customer Miller has been promised a free delivery of 1000 promotional catalogs. Please enter an appropriate order in the system.

Wrong: Please create a sales order of type FD "Free-of-charge Delivery" and enter 1000 for the sold-to party, 1000 for the order quantity, and "Cat01" for the material.

Keep the Tasks Short

The processing time for a task should be between 5 and 10 minutes. The total processing time for the whole session should be no more than two hours.

Create the System Data