Announcements/Reminders

• W5 Workshop focuses on
1. piloting and evaluation status updates on your
mini-project
2. Mid-term preparation
• Midterm Wednesday NEXT WEEK (Feb 14th)
– Preparation document <- do this early
– install Lockdown Browser to your laptop
– Please fill out this piazza poll to communicate the
mode and location you prefer to write your exam
 Last Class

• outlined the steps in task centered design

• listed the elements and characteristics of a good task
example, and demonstrate these when writing task
examples
• did a “walkthrough” of an interface design using a
task example
 Turn to your neighbour

1. Human needs; Human tasks; Task examples – put

these in order of least design-specification to most.

2. What are the 4 steps that take us through task-

centered system design?

3. What makes for a good task example? (There are 6

elements.)

4. What are the pros and cons of using task-centered

system design?
 cpsc 344: introduction to HCI methods

requirements

© 2024 Cang with acknowledgements to Yoon & MacLean class w05b

 learning goals
• define and give examples for different types of
requirements
• be able to establish appropriate requirements for a given
task example

5
 GOALS Big Picture – WHEN do requirements happen?
Understand USERS: Understand DESIGN: REFINE Design: CONFIRM & debug:
• who they are • design space and risks • by element • performance in
• their key tasks • choose design approach • considering task real use
• varied contexts

Release!
Make use of: Make use of:
• requirements • graphical design
Examine existing:
MATERIALS / METHODS

• task examples, analysis • interface guidelines

• user tasks &
• real & virtualized users • style guides
• objectives
• technology options • real & virtualized
• contexts
• company IP users
• interfaces
Field
testing
Evaluate w/: Evaluate w/:
Evaluate w/: • observation • usability testing –
• observation • interview/quest controlled,
– many kinds
• participatory uncontrolled
• ethnography interaction • heuristic evaluation
• interviews, • task walk-throughs
questionnaires
• task examples
• task analysis

PRE EARLY MID LATE

PRODUCTS

DESIGN DESIGN DESIGN DESIGN

• user and task • throw-away prototypes • testable medium- • alpha/beta
descriptions • design direction fidelity prototypes systems or
• design requirements • risk analysis • complete
specification
6
K MacLean - derived from version by Saul Greenberg (U Calgary)
 the task centered view of
process/project
step 1: identification (in pre-design) w05a
• identify specific users
• articulate and analyze examples of realistic tasks

step 2: requirements (finishing pre-design) w05b

• decide which of these tasks and users the design will support

step 3: conceptual design (in early design) w08

• base ‘wireframe’ of design representation and interaction
sequences on these tasks, emphasizing user “mental model”

step 4: task walkthroughs (earliest evaluations of designs) ~w10

• using your design(s), walk through the tasks to test proposed
interface
what are requirements?
stable descriptions of the users’ aspirations, needs,
capabilities, goals, constraints, expectations, etc. that form
a sound basis to start design activities.

8
where does conceptual design orange box =
data / analysis
fit into design process?
purple box =
roughly like this: create design

in reality, lots of iteration

green box =
design outcome
START
task
scenario
examples

conceptual interface
requirements design design
conceptual
model

increasing “fleshing out” of early design

 types of requirements
• functional requirement: what the product will do
• data requirement: the characteristics of the required
data
• environmental requirement: the circumstances in
which the product will operate – physical, social,
organizational, technical
• user characteristics: the key attributes of the
intended user group
• usability/UX goals

10
 grocery list task example
Andy is doing the weekly menu planning for her family of 4. She
chooses a set of recipes that suit the season, available prep
time, current individual dietary eccentricities and her own
preference at that moment.
Many of this week’s choices are regulars. She creates a
shopping list of ingredients, ordered by where they can be found
in the grocery store. Her partner Jean, who does the actual
shopping and is more familiar with the store, supplies
“feedback” on any errors she makes.
When a recipe requires an ingredient that was already needed
for an earlier day’s meal, it is incremented. After quickly getting
through the week’s meals, she can easily add a few regular
items like milk, bread, cereal and juice. After Jean has left with
the list, she realizes she’s forgotten to check the pantry for
staples like flour and rice.
 Turn to your neighbour
Find passages in the grocery list task example that
represent these requirement types
• functional requirement: what the product will do
• data requirement: the characteristics of the required
data
• environmental requirement: the circumstances in
which the product will operate – physical, social,
organizational, technical
• user characteristics: the key attributes of the
intended user group
• usability/UX goals
12
 usability or UX focus is rarely pure
meeting usability requirements will/should often
influence functional requirements and vice
versa. For example,
needed speed of response from system to user
 give feedback in 0.3 sec
 implementation platform
desired user context – e.g. driving
 must work on mobile platform
 voice output, speech input

14
 three steps to requirements

1. identify the human needs

which the proposed interactive system will support:
task, goals, conditions; current problems and strengths

2. identify all the users & other stakeholders

who do or will perform the activity:
groups, capabilities, motives, needs

3. set levels of support (metrics)

functionalities the system will provide;
environmental constraints and user/stakeholder
characteristics
15
 metrics:
how we know if we have succeeded
quantitative metrics:
• you can count them
• e.g., speed of performance, incidence of errors, ease of learning
the system, perceived workloads (e.g., NASA TLX), generic
usability score (e.g., SUS)

qualitative metrics:
• descriptive and illustrative
harder to directly count and measure
• e.g., stories about user impressions and frustrations, and their
change pre- and post design; critical incidents; product “buzz”
…
17
 review /
on your own
quantitative usability metrics

performance
• speed
– how long it takes to perform an activity
– how many people it requires to complete

• error rate
– how often will errors happen
– how critical will they be to success

18
 review /
on your own
quantitative usability metrics

learning to use the system

• how much time will it take
• what/ how much background is required
• what proportion of users require extra help
• how much speedup do experts ultimately obtain

ease-of-use (subjective)
• do users find it easy to use the system

19
 review /
qualitative usability metrics on your own
these can be described
recovery from errors
• can users fix mistakes
• how difficult is it

retention of learned skills

• do users continue to perform well after breaks

ability to customize
• can users control how they use the system

ease of reorganization of activities

• can the system be used to do other things
• does the system support changing needs
20
 can requirements change?

requirements should be stable

if based on good data

but not rigid

they may shift over time, in particular as design
reality dictates what is possible / feasible given other
constraints.

21
 in your mini project report (W06)

we don’t explicitly tell you to list the subset of

users you are going to support.
 but, they must clearly reflected in the requirements
that you come up with

your requirements should generally:

- be written in full sentences
- make sense in relation to your findings
(you’ll have to justify them!)

22
 activity – (group)

Part 1 – read and analyze the given task example

 Types of Requirements

• functional requirement: what the product will do

• data requirement: the characteristics of the required
data
• environmental requirement: the circumstances in
which the product will operate – physical, social,
organizational, technical
• user characteristics: the key attributes of the
intended user group
• usability/UX goals

25
 activity – (group)

Part 1 – read and analyze the given task example

Part 2 – identify requirements

 activity – (group)

Part 1 – read and analyze the given task example

Part 2 – identify requirements

Part 3 – Consider how data might flow. Are there certain

data dependencies? Are there tasks that must happen
before others? (E.g. add item should occur before
delete/edit item) Can you create a diagram of the data
flow? Indicate where you expect the most and least rigidity.