………………………………………………………………………………………………………………………………………………

DEFINING AND
DOCUMENTING
CHAPTER THE USER’S
3 NEEDS – PART 1

LEARNING OUTCOMES

By the end of this chapter, you should be able to:

1. Describe the different aspects of context setting and feasibility assessment

2. Document a problem using the simple task analysis and specification
technique
3. Describe techniques to collect information about users

CUE400 USABILITY ENGINEERING

 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

INTRODUCTION

Ask yourself what you need to know to understand a problem, and you will
probably conclude that the issues from our usability model are precise what you
need. Understanding the user’s characteristics, the tasks, and the setting that your
user interface needs to address can go a long way toward specifying the problem
you need to solve.

There are two terms of analysis and specification. A quick definition is in order.
Analysis is the activity of understanding and breaking down a problem, so task
analysis means understanding the user’s tasks at both a high and a detailed level.
Specification means “documenting” or “describing in detail”, so a task
specification is the documentation of your understanding of the user’s tasks. It is
not enough to understand without documenting, and vice versa.

3.1 CONTEXT SETTING AND CONTEXT SPECIFICATION

Suppose you are the CEO and only employee of your own user interface
development consulting firm. A potential customer calls you with a project that
they would like you to do. Take a few minutes to think of some questions you
would need to answer before investing resources in this customer’s project, then
continue reading this text.

 You probably came up with some questions like those:

 What kind of platform and programming language will I be using?
 What is the customer’s time frame for the project?

1
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

 Where will I be working: at the customer’s sote, at my site, or somewhere

else?
 How much money does the customer want to spend on this project?

The answers to such questions set the context for your work. They give you, the
developer, an idea of the feasibility of a project before you jump into the middle of
a large effort. For example, if the customer is expecting you to deliver a project on
a platform that you know nothing about and is not willing to pay for your training,
the project may not be feasible for you.

Your context analysis and specification minimally should explore and document at
least three pieces of information :

 Usability expectations
 Needs
 Feasibility

Usability Expectations

Users may wish you to develop an overview document in which they establish their
general usability expectations for the proposed user interface. Such a usability
expectation specification might include :

 Overriding usability goals. If the user expects that overall the user interface will
be easy to learn, easy to use, fun to use and so on, it is important to
document exactly what the user means by this. This document should
specify as carefully and in as much detail as possible how you will
operationalize and assess these goals.

2
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

Needs

Usability engineers should analysed the need for the new system before continuing
with the rest of the usability lifecycle (cf, Hix and Hartson 1993). A needs
specification might include :

 A rationale to establish and document that a new user interface is needed.

 A statement of the goals and expected use of the proposed user interface.
 A feature list of the proposed product. These features might specify
operational characteristics of the system, platform information, and so on.
In other words, the feature list could spell out what specific things a user
could do with this proposed user interface and in what environment the
interface will be used. The feature list could also describe particular
attributes of the proposed interface. For example, the feature list might
specify that the interface supports automatic backups or provides “undo”
mechanisms.

Sometimes, the developer will define the need for the customer. For example, the
developer may make a proposal for the features of a proposed in order to convince
the customer that they need to pay for the development effort.

Feasibility

A feasibility specification might include :

 Costs and resources needed to build the user interface

 Potential constraints and underlying assumptions for the proposed user
interface. For example, you might specify the target platform as an
assumption or constraint for this project.

3
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

Regardless of whether or not you conduct and document a formal needs analysis,
an informal assessment of feasibility, a statement of context, or an overview of the
project’s expectations, it is critical to identify a process for context setting and to
produce a context specification.

3.2 UNDERSTANDING USER’S PROBLEMS BY

UNDERSTANDING THEIR TASKS

Once the context for a user interface has been established and the project is known
to be feasible, the usability engineer must develop a detailed understanding of the
user’s problem.

A number of strategies have been suggested to analyse the user’s problem and to
produce a description of the tasks that the user or customer will do with the
interface.

In the following subsections, we briefly describe three methods for analysing and
specifying user tasks, then we present our simplified and modified strategy of task
analysis and specification.

3.2.1 Strategy 1 : Use Case Analysis

Within the Unified Software Development Process, on element of requirements

specification involves the construction of use case models. Use cases describe the
expected functionality of a target system. A use case model documents how the

4
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

target system will interact with people and systems that are outside the target
system.

A use case is a representation of how external actors, such as representation of

how external actors, such as users, will use the system under development. The
idea in use case analysis is that the software engineer understands the problem in
terms of how the target system will interact with external systems. Then he or she
documents the problem by building a visual model that shows the ways that
external actors use the system.

Use case analysis and modelling have some advantages as a task analysis and as a
specification tool. For example, use case models and the models that follow
emphasize sequencing and work-flows, which force the software engineer to
understand these issues. Use case models also facilitate a fairly seamless transition
to an object-oriented design for the interface itself. Finally, a number of excellent
commercial CASE (computer-aided software engineering) products exist to
support use case modelling and the Unified Software Development process.
However, use case analysis and modelling also have some disadvantages as a task
analysis and specification tool. Since use cases are intended to show the
functionality of a target system, rather than to describe the tasks that a user will
perform with the system, a use case analysis can easilty become system centred
rather than user centred.

3.2.2 Strategy 2 : Analysis Using Scenarios

Rosson and Carroll (2002), Rosson, Carroll, and Rodi (2004), and Carroll (2000)
describe the usability engineering methodology called scenario-based development
(SBD). The emphasis of the SBD methodology is on the development and
evolution of scenarios from problem description to eventual design. In the analysis

5
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

phase of SBD, the usability engineer collects problem scenarios from the relevant
stakeholders in the problem. Rather than translating these scenarios to another
specification format, the scenarios themselves form the specification. The SBD
methodology is highly iterative, and developers continue to refine and modify the
problem scenarios at the same time as they are developing scenarios of the design.
Developers also practice “claims analysis” as a way to identify emphasis points and
resolve apparent differences among scenarios.

3.2.3 Strategy 3 : Hierarchical Task Analysis

Another way of describing a user’s task is in terms of the hierarchical relationships

among them. This activity hierarchical task analysis because the outcome is a
hierarchical breakdown of tasks (cf. Dix, Finlay, Abowd, and Beale 1998).

The idea of task analysis is to understand the user’s tasks by decomposing them
into the detailed subtasks that define them. By developing a hierarchical
breakdown, the usability engineer can understand the user’s tasks in both an
abstract and detailed way simultaneously. The usability engineer can also
understand detailed and low-level tasks in context. The task analysis is done
completely from the user’s perspective and does not describe system sequencing or
workflow. During and after the process of understanding the problem via task
analysis, the usability engineer documents his or her findings in a task specification.
The specification details the hierarchical task structure, as well as details of the
tasks.

3.2.4 Which Approach to Use?

The three techniques that we have mentioned, use case analysis and modelling,
scenario-based development, and task analysis and specification are not mutually

6
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

exclusive. In fact, Rosson and Carroll show an example of a hierarchical task

analysis and diagrams as support for their scenario-based design (2002, 59). Use
cases may be derived from scenario descriptions, and step-by-step scenario
descriptions may be used to expand use cases. Unified Software Development
Process sequence diagrams may show a kind of task decomposition, similar to
what might result from a hierarchical task analysis.

The simplified task analysis and specification technique produces a detailed

document that can then be used to drive a design. This document describes in
detail how the users will use the system that the usability engineer is eventually
going to build. The document does not specify how the designer will build the
eventual system, it does not show the look and feel of the eventual system, and it
does not describe the flow of the system activities necessary to accomplish the
tasks. The focus of this effort is on understanding and providing enough detail
about only the user’s problem (the tasks) that you as the designer can solve. The
document that is produces should be so detailed and specific that it leads directly
to a design.

A CASE tool can help you develop use case models and the task specification.
Alternatively, you can generate your specification with drawing and word
processing tools.

3.2.5 Our Analysis and Specification Strategy : How to Do It

What kind of information do we need to understand a user’s problem? It would be

useful to know what tasks the user planned to accomplish with the proposed
interface.

7
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

It would be helpful if the user described the problem at different levels of details.
An abstract descrition would help us to understand “the big picture” of the
problem. Detailed descriptions of the components of the problem would help us
with a design that exactly satisfies the problem.

First, we start with analysis. We need to understand what tasks the user wants to
support in the user interface. We will start with some high-level scenarios that
acquaint us with how the target user interface will be used. Based on these, we will
identify the user roles and a number of use cases relative to the interface. We will
keep track of what we have learned about the problem by using the notational
techniques of UML and loosely following the methodological approach of the
Unified Process. The use cases that we identify will help us to translate the
scenarios, which describe specific situations, into more abstract descriptions of
user tasks. Based on our use cases, we will work with the user to understand the
hierarchical breakdown of the task, so that we can understand the task at both a
conceptual and a detailed level. At the top level of the hierarchical, we will have an
abstract description of the big task. We will then decompose this task into
subtasks, each with more detail than the top-level description.

Next, we do the specification. We will draw pictures of our use cases that we
derive from our scenarios. We will draw hierarchical decomposition diagrams for
each task and subtask. And, because we will learn much more about the task as we
proceed, for each task and subtask, we will generate a detailed, point-by-point
specification of the task in narrative form.

We document constantly. We keep track of every part of our understanding of the

problem as we go. We document everything that we learn as we go. So while we
are doing the analysis activity mentally and in a group discussion form, we generate
specification documents as we learn. We can always change or enhance the

8
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

documentation we have, we probably will use a more iterative process. The

document will contain the following :
 A title page and table of contents
 A high-level narrative description of the user’s tasks
 A set of scenarios of specific examples of the user’s tasks along with an
informal use case model of each scenario.
 A high-level use case model created from a consolidation of the information
from the scenarios. The informal use cases, and the high-level narrative
description.
 A hierarchical description of the user’s tasks in pictorial form. We will call
this the task analysis diagram because it is an externalization of our
understanding of the problem. Each task and subtask wil be specified by a
name in a “box”. The picture will give us a clear idea of how the task has
been decomposed. The tasks in the diagram should be numbered following
a hierarchical numbering strategy. The hierarchical of tasks starts with
general tasks and breaks them down into very specific tasks. Typically each
“box” in the hierarchy corresponds to a task that the user will perform with
the interface.
 A text description of each task in the diagram. These details are difficult to
include in a hierarchical diagram, so the text description wil help us keep
track of the details.

In brief, our task analysis and specification process will proceed as follows:

Step 1 : We will start with a narrative description of the tasks that the user
wishes to accomplish with the proposed user interface. This
description will like be incomplete.
Step 2 : Following the narrative description, we will look at a number of

9
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

scenarios describing specific tasks that someone might do with our

interface.
Step 3 : For each scenario, we will build an informal use case diagram.
Step 4 : From the collection of informal use case diagrams, we will extract
what seem to be the “things” that our users are operating on. As
much possible, we will try to identify what the attributes of these
“things” are. Stiller and LeBlanc (2002) call these “things” primary
classes. We will call them primary entities.
Step 5 : With our informal use case diagrams and models of primary entities,
we will consolidate to form a high-level use case diagram that shows
what tasks a user might perform with the interface. We will use the
primary entities to form the terminology of the use case diagram.
Step 6 : For each use case, we will perform hierarchical task decomposition
(hierarchical task analysis).
Step 7 : For each task in each task decomposition, we will develop a
multipoint descriptive narrative.
Step 8 : For each task, we will consider any other information that the user
has shared, perhaps about the structure of data or any details of the
functionality, and incorporate this information into the task
decompositions and descriptive narratives.

3.2.6 Task Analysis and Specification Process Example

The starting point in our analysis and specification process will be to build a very
high-level description of how the used will use the proposed system. Our first
three steps will be to identify the high-level tasks and who is doing them.

Step 1 : Develop a narrative description of the tasks that the use wishes to
accomplish.

10
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

Step 2 : Collect specific scenarios of specific tasks that someone will do.
Here are several scenarios:
Scenario 1 : Sepideh is gong to bake a cake. To do this, she starts by
cleaning the kitchen amd gathering ingredients. For example, she
gathers flour, eggs, sugar, butter, baking powder, salt, and vanilla
extract.
Scenario 2 : Following the recipe, Daryl mixes the ingredients. He
sifts the dry ingredients and mixes up the wet ingredients and then
combines the wet and dry mixtures.
Scenario 3 : Brian pours the batter into a greased pan to cook the
cake.

Before going to Step 3, we need a little more information about use case diagrams.
The goal of use case diagram is to illustrate the relationship between actors outside
of the system (in this case, the user interface) and the tasks or uses that they will
make of the system. Each of the interactions between actors or task that can be
achieved by the system can be considered to be a use case. Actors are anything
external to the system that interacts with the system. Each actor indicates a
possible role in which someone or something could engage. For example, in user
interfaces, the actors outside of system are the users of the interface. The icons for
the use case diagram are simple: a stick person for an actor, a line for a
relationship, and an oval for each of the use cases (refer Table 3.1).

11
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

Table 3.1 Summary of Use Case Icons and Their Meanings

Step 3 : For each scenario, identify graphically what the task is and who is
doing it using informal use case diagrams.

The use case diagrams can be seen in Figure 3.1, 3.2 and 3.3.

Figure 3.1 Use Case for Scenario 1 of “Bake a Cake” Example

Figure 3.2 Use Case for Scenario 2 of “Bake a Cake” Example

12
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

Figure 3.3 Use Case for Scenario 3 of “Bake a Cake” Example

Step 4 : Identify the primary entities or “things” in the tasks.

First, let’s consider our actors : Sepideh, Daryl and Brian. From the
information that we have, we know that their structure is identical.
Each actor has the following attribute of interest : graduate student
name. However, except for different values for this attribute, the
actors are identical. We reason that each of our actors are just
instances of a class: Graduate Student Cake Baker. Based on the
narrative and the scenarios, nothing distinguishes one graduate
student from another except their names. None seem to have any
unique characteristics. Kitchen supplies is a repository.

How about “things” that are acted upon? It seems at least two
things are acted upon : Kitchen and Ingredients. Kitchen does not seem
to have any particular attributes as there seems to be only one
instance of this. Ingredients has attributes of Ingredient Kind and Wet or
Dry. We also seem to have a thing called Pan, which needs to be
Greased. Finally, we have the Recipe. Let us assume that Recipe follows
a conventional format for which amounts of ingredients are listed
followed by the instructions to assemble the cake. By looking at the
“things” that we have and their attributes, we may be able to identify
some potential user tasks.

Step 5 : Consolidate the information from the high-level narrative scenarios,

13
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

informal use cases, and primary entities into a set of use case
diagrams.
At the highest level, our use case diagram looks like the diagram in
Figure 3.4.

Figure 3.4 High-Level Use Case Diagram for “Bake a Cake” Example

What can we consolidate? The first use case shows two different functions, and
they seem to be at a more detailed level than the sue cases for the other scenarios,
So we will combine and compress the informal use case daiagrams into a diagram
in Figure 3.5.

Figure 3.5 Consolidated Use Case Diagram for “Bake a Cake” Example

The use case diagram is just one strategy that the Unified Process uses to capture
and thoroughly specify system requirements. Even the simple diagrams that we
showed in Figure 3.1 through Figure 3.5 would have to be supplemented with

14
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

textual description for each of the use cases if they were serving as requirements
specifications.

For our purposes, we will simply use the use case diagram as a link between our
scenarios and the task analysis.

Step 6 : Break down the tasks hierarchically (task analysis).

Now, we are going to practice breaking a task down hierarchically.
This is important because we need to understand the task at a
detailed level so that we may be able to check our understanding
against that or the user.
Our case diagram had one high-level task with three subtasks. On
that basis, we have the task breakdown in Figure 3.6 for the first
two levels of the task analysis.

Figure 3.6 High- Level Task Analysis for “Bake a Cake” Example

Now, let’s expand the task analysis to provide a little more detail. Assume that our
details are either coming from the work that we have already done or from
additional input from a user. We will get a diagram similar to the one in Figure
3.7. As you look at the diagram in Figure 3.7, note how important it was for us to
have thought about the primary entities. As we start the process of hierarchical
task decomposition, having a good idea of the key objects of interest will help us
understand the tasks at a detailed level.

15
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

Figure 3.7 Example of Hierarchical Task Analysis Chart

3.2.7 Completing the Specification

This is only a partial solution which we did not include many details, but we should
notice some things in Figure 3.7. Time order is not necessarily from left to right.
Does it really matter if you grease the pans first or preheat the oven? Since
subtasks shown are activities, most boxes begin with a verb.

Let’s look at one of the subtasks in the diagram and provude some additional text
information about the subtask. We pose this additional information as a series of
questions followed by answers about the task. While the questions may seem as if
they could be answered in a word or two, the more detail in the answer the better.
 What is the goal of this task?
 Is this task a subtask of a larger task?
 What subtasks define this tasks? Where is the task in the graph?
 What noninterface functions does this task require?
 What kinds of inputs or actions does this task require from the user?
 What kinds of outputs or results occur by virtue of performing this task?

16
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

 What automatic actions does this task expect from the system?
 What special characteristics of this task should we record? The user might
have some special requests.

As Hartson, Sioci and Hix (1990) and Hix and Hartson (1993) note, tasks may
have some required sequencing, so we add the following two questions about
sequencing to the list :

 In this subtree, is there a task that must come before this one?
 In this subtree, is there a task for which this one is the immediate
predecessor or is there a task that can co-occur?

We also add the following question about primary entities to the list :
 Which, if any, entities (or things) are involved in this subtask?

Because tasks are not always completed, we ask this question :

 How can this task (or end in noncompletion)? The answer may be that
failure can occur due to outside (of the interface) conditions or it may be
because another task or subtask was not included. Or it simply may fail
due to user input error, At this point we probably should assume that
any task could fail due to user input error, but it may be helpful to
document the nature of the user error. We are trying to indicate other
potential problems as well.

Finally, during analysis and specification, we try to get as much information as we

can about the task and usability characteristics, as suggested by our model of
usability :
 How frequently is this task peformed?
17
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

 How rigid is this task, especially in terms of its sequence or input

options?
 Are there unusual situational constraints to consider?

Let’s try to fill in the ansers to these questions for the task Grease Pans.

 What is the goal of this task?

The goal of Grease Pans is to put enough grease on the pans so that (1) the
cakes do not stick to the pans while they are cooking and (2) we can easily
remove the cakes from the pans once the cake is done.

 Is this task a subtask of a larger task?

Yes. This task is part of Prepare Kitchen.

 What subtasks define this tasks?

None. This task is at the bottom of the hierarchy.

 What noninterface functions does this task require?

None. (Note : For the current system, this question may not seem to make
sense because there is no software interface. With a software user interface,
any actions outside of the user interface software that are involved in
completing this task should be documented. For example, if the the task
required a binary search, that activity would be recorded here.)

 What kinds of inputs or actions does this task require from the user?
The user must decide whether to use a solid or spray shortening to apply the
grease to the pans. (Note : In a computer system, if a task required a value

18
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

or input from the user, the answer to this question would be the kind of
user input necessary to complete the task.)

 What kinds of outputs or results occur by virtue of performing this task?

Here the result is that the pans are greased.

 What automatic actions does this task expect from the system?
Suppose that an alarm went off when the user had applied too much grease
to the pan. That would be an example of an automatic system action. In our
original use case diagram, we indicated that the kitchen supplies are external
actors to the task of baking a cake. Here you might note that the kitchen
supply “grease” is used.
 What special characteristics of this task should we record? The user might
have some special requests.
Suppose that the person who will eat your cake is allergic to dairy products,
For the task Gather Ingredients, you may note to use olive oil instead of butter,
Nonstick pans or the use of cupcake liners do not require this task to be
completed.

 Is there a subtask that must come immediately before?

The task Find Recipe should occur before the tasks Preheat Oven and Grease
Pans, The recipe will contain information on the required temperature for
the oven and the type of pan appropriate for the cake.

 In this subtree, is there a task for which Grease Pans is the immediate
predecessor or a task that can co-occur?
No, although technically you can grease the pans while the ovens is heating
to the required temperature.

19
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

 Which, if any, primary entities (things) are involved in this subtask?

The primary entities are Pans and Grease. (Note : are these listed as primary
entities from the use case analysis?)

 How can this task fail?

If I cannot find a pan or grease, then the task cannot be completed. In other
words, this task can fail only if I fail to collect these objects.

 How frequently is this task performed?

In this context of baking one cake, the task is performed once per pan.

 How rigid is this task?

The task of greasing pans is relatively constrained in the sense that grease
must go into the space of the pan and nowhere else. On the other hand, the
choice of type of grease and how it is applied might have a number of
alternatives, including shortening applied with a paper towel, olive oil
applied with a pastry brush, and so on.

 Are there any situational constraints?

None.

 What, if any, are the specific usability expectations (e.g, ease of use, ease of
learning, task match, flexibility and satisfaction) for this task,a nd how do we
anticipate determining if we have satisfied the expectations?

3.2.8 Task Analysis “Do’s and Don’ts”

Here are some hints that will help you to analyse tasks and documents your
analysis:
20
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

Do :
 Use verbs to describe user actions. Use of verbs in the names of your tasks
and subtasks will help to convey the idea of actions.
 Give details. The more details you can include in your task analysis, the
more completely you will have specified your problem. The more complete
your specification, the more likely it is that you will design and implement a
solution for the problem that the user had in mind.
 Keep your hierarchical diagram neat and organized. We encourage our
students to assign hierarchical identifiers to each task and to show the
identifiers on all diagrams and narrative descriptions. In the “Bake a Cake”
example, the task Prepare could have been numbered 1. The tasks below
could have been numbered 1.1 (Prepare Kitchen) and 1.2 (Gather Ingredients).
The tasks below Prepare Kitchen could have been numbered 1.1.1 (Preheat
Oven), 1.1.2 (Grease Pans), and 1.1.3 (Find Recipe). Having these numbers will
help you to verify that your diagrams and narrative descriptions are
internally consistent. In addition, you can carry your numbering forward
into your design to ensure that your design supports the tasks from your
specification.

Don’t :
 Impose your own understanding onto the user. Do not assume that your
understanding of the situation before the analysis is the same as the user’s
understanding.
 Impose artificial sequencing n the user. Do record essential sequencing
information, but do not impose a sequence of tasks on your user.
 Reproduce a hierarchichal menu design. Suppose that you are specifying
some file management tasks for a user. You might come with an analysis
similar to Figure 3.8.
21
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

Figure 3.8 Draft File Management Task Analysis

These are typical options on a standard file menu in many applications.

However, the terminology is very system oriented, and in this context, the
term File is a noun and not a verb. A better hierarchical breakdown, from
the user’s perspective, might be the one in Figure 3.9 :

Figure 3.9 A Better File Management Task Analysis

3.2.9 Task Analysis Challenges

Task analysis is hard, even for a task as relatively simple as baking a cake. The
following are some challenged you are likely to face:
 You might like to know if your analysis is complete and correct. While some
techniques for formal proofs of correctness exist, especially for software
requirements, these proofs are often difficult to perform.
 It is sometimes tough to know how simple enough for the subtasks at the
bottom of your chart. For example, in the case of baking a cake, should you
have a different task for sifting salt into the flour than sifting baling powder

22
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

into the flour? The answer can depend on how similar the tasks are and
whether you can document the variations in the narrative.
 Many task analysis methods assume that the user will not make errors.
Under this strategy, your specification may not deal with errors, but
experience suggests that error handling constitutes a large part of the activity
in many users interfaces. In the cake example, we have not shown what the
user will do if the recipe cannot be found or if the oven catches on fire, yet
we know from our own experiences that these problems could arise.

3.2.10 Task Analysis and Specification Errors

The following are some typical errors to avoid as you conduct your task analysis
and prepare your specification :
 Avoid inconsistencies between the items in the chart and your written
descriptions. In particular, be careful to use the same spelling conventions
for the names of your subtasks in both your chart and text description and
make sure your task numbers in the chart and narratives match.
 Avoid tasks that appear only in the chart or only in the written description.
 Avoid spelling and grammar errors. Such errors make our work appear
unprofessional at best and may be misleading at worst.
 Avoid describing the task as if you were doing it. Your description of the
task should be from the perspective of the user, not yourself. When in
doubt, ask the user how to describe the task, rather than guessing about it.
 Avod analysis with insufficient detail. When in doubt provide more detail,
not less. If some of the information is redundant or not necessary, it will
disappear in the design phase.

3.2.11 Task Versus Implementation

23
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

Task analysis is not implementation. Unfortunately, it is really tempting to jump

into implementation, even unwittingly. An example of confusing implementation
with task analysis can be found in the trap of multiple inheritance.

The Trap of Multiple Inheritence

Suppose you are specifying an interface. The user wants to be able to cut and paste
informatin from two different data entities (say, text and a graphic). The user may
even use the terms cut text, cut graphics, paste text and paste graphics while describing
these tasks to you. The trap of multiple inheritance would be to describe the tasks
as shown in Figure 3.10.

Figure 3.10 The Trap of Multiple Inheritance

3.4 DEVELOPING USER PROFILES

To get a good interface, you have to figure out who is going to use it and what they
are going to do with it. Our usability model suggests that user expertise and
motivation impact the usability of a user interface. A more extensive list of issues
to explore includes : (1) background issues about users (2) user feedback about

24
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

job functions (3) how this interface would impacr a user’s job and (4)
organizational and workflow considerations.

We would like to have detailed understanding of potential users, recognizing that

our users may be from different groups with different needs. Groups such as
children may have different needs and requirements. It may also useful to know if
your system has a social impact : Does your system displace workers? How does
this influence the attitude of future users of your system? Will yoru system have
regular users and/or incidental users?

3.4.1 How Use Characteristics May Impact Your Final System

According to Mynatt (1990), by identifying characteristics of the users, it can help

the developers design and build interfaces that are appropriate and usable.

There are three (3) categories of users, based on their computer knowledge :

(1) Novice Users

They have litte of no knowledge if using computer system.

(2) Knowledgable Intermittent Users

They have used a number of different systems but on a sporadic basis.

(3) Frequent Users

They can be considered to be experts or “power” users, completely familiar
with a given system or systems, and use them in an ongoing and regular basis.

Below are the suggestion interfaces based on the categories :

25
 Defining and Documenting the User’s
CHAPTER 3 ..........................
Needs – Part 1

(1) Novice Users – Interfaces with a small number of commands or actions and
reducing of error as much as possible, even if it means limiting some advanced
capabilities.

(2) Intermintent Users – They can handle many more commands or actions, but
consistency and simplicity of commands are still critical for this group. They
should be offered the opportunity for safe but educational exploration.

(3) Frequent Users – They want fast response and shortcuts, and they may consider
all but the mst minimal feedback to be cumbersome.

If there are combination of user types, you may provide a layer interface, in which
each group can “find” its layer.

3.4.2 Where to Start Building User Profiles

As with task analysis, a number of techniques can be used to get information about
future users, including interviews, surveys, direct observation, and ethnographic
techniques. In your data gathering, you will likely be trying to collect information
about the usability model variables of user expertise (including language, skills, and
background) and user motivation. You may wish to identify the users; level of
computer knowledge as suggested by Mynatt (1990). You might also want to learn
aboth the users’ ages and cultures. A large number of today’s interfaces are
developed for people who are twenty to forty years old. People outside of this
group may have different needs than those in it. In your data gathering, be sure to
document who provided information, how these people were chosen, how you
collected the data, and how you obtained permission from the users to collect
information about them.

26
 Defining and Documenting the User’s
………………………………… CHAPTER 3
Needs – Part 1

3.4.3 Structure of a User Profile Document

What are the the types of information to be included in the user profile document?
There are user characteristics (such as age), user skills, a description of how users
will use in this interface, psychological characteristics (such as motivation,
knowledge and experience), job and task characteristics (such as frequency of use),
and the users’ physical characteristics, including physical handicaps.

SUMMARY

There are two documents to help you specify the problem that you will eventually
be solving with your interface: task specification and user profiles. You may also
generate documentation about the context and feasibility of your project. These
documents justify the need for your project, describe the tasks that will be done
with the interface, and describe the users.

27