CMPT 363: User Interface Design

Fall 2022

Week 5: Gathering Requirements, Task-Centered Design

Instructor:Victor Cheung, PhD
School of Computing Science, Simon Fraser University

© Victor Cheung, 2022

 What Level of Fidelity?

https://www.youtube.com/watch?v=HUP6Z5voiS8
 Recap from Last Lecture

• Different levels of prototyping

• Low Fidelity Prototypes (LFPs) – sketches, story boards, simple materials
• Medium Fidelity Prototypes (MFPs) – simulations, materials closer to the final product
• High Fidelity Prototypes (HFPs) – nearly fully implemented, looks and behaves like the real thing
• Wizard of Oz – a way to let people experience the design while it is still being developed
• Variations of prototypes showing breadth or depth by varying features and functionalities

3
 This Week

• Identifying Contexts & Users

• Task-Centered Design
• Gathering Requirements

• Project Part 1 available on Canvas, due on 14 Oct

• Read the description documentation
• Ask questions at Canvas Discussion

4
 Project Part 1

• Overview
• To redesign the interface for the dining feature of the SFU Snap app that allows
its users to find information about dining on SFU campuses
• Part 1 (due on 14 Oct, 11:59p, done individually)
• Heuristic Evaluation on the dining feature in the SFU Snap app
• Context & User identification, Design requirements gathering (we’ll be covering these this week)
• Can base your requirements on usability problems or good usability examples (see description doc)
• Come up with something non-trivial (e.g., not “SFU login required”, “notification shown immediately”)
• Sketch per functional requirement, then create LFPs
• Make sure you have scheduled enough time!
5
 Designing a Traffic Button

• Expensive, likely to break down after several years

• Want to come up with a design with no moving
parts that lasts longer and cheaper to make
• ~5 Min Activity – Things to consider?

Older versions of Novax’s APS buttons

6

Courtesy of Artun Cimensel (class summer 2020)

 Designing a Traffic Button (cont’d)

• A vibrating piezoelectric button

• Sensors detecting pressure or mechanical stress
(no moving parts)
• Visual cue for directionality
• Haptic and audio feedback

7
 DESCRIBE A
TREE SWING

Everyone has their

own interpretation

Need a way to figure

out what users need

8
 Involving Users in Ever y Step

Understand/
• Understand/specify context of use specify
context of
• Interview users & examine tasks use

• Specify requirements
• Verify & prioritize with users Evaluate Specify
designs requirements
• Create design solutions
• Design with users (co-design)
• Evaluate designs Create
design
• Invite users to assess solutions 9
Identifying Contexts & Users

So we can understand & specify context of use

10
 Contexts & Users

• Contexts – the situation or environment that influence decisions

• When/where: time and location at which tasks are carried out
• Who: people with whom decision making is involved
• What: considerations and information needed to make decisions
• How: steps taken to get things done
• Users – the people who carry out tasks and make decisions
• Demographics (e.g., gender, age group, education background, capability)
• Hopes & fears (e.g., stressed, don’t want to make mistakes)

11
 Why Are Contexts Important?

• When/where: time of day, geographic location, physical location

• Who: roles, who needs to be notified, who is affected
• What: regulations, policies, dependency on other resources
• How: protocols, standards, norms, challenges
• Together these information impose constraints and implications to the design for it to adhere to
• Use of language
• Priorities of usability goal
• …etc.

12
 Why Are Demographics Important?

• Demographics describe the type of the users, provide insights into their
approach and attitude towards an interface
• Characteristics: education background, capability, attitude towards computers, …etc.
• Leads to complexity and accessibility of interface (e.g., use of words, colour,
modalities, UI layout)
• System use: novice/expert/casual/frequent
• Novice users need step-by-step prompts, more constraints, and clear information;
expert needs less, and likely to appreciate advanced control and shortcuts
• Casual users need more reminders, recognition over recall
• Frequent users benefit from shortcuts, automation

13
 Why Are Hopes & Fears Important?

• Hopes & Fears describe the mental/emotional state the user is in, thus affecting
their judgements
• High stress level requires more fail-safe mechanisms, even a “calmer-looking” interface
• Fear of making mistakes benefit from an assuring interface with lots of feedback and
error handling
• Uneasiness towards computers requires more reassurance, even a “non-computer”
look and feel
• Relaxed moods are more open to suggestions
• …etc.

14
 Where & What of Users

• Ideally through direct contact (e.g., same company, company being consulted)
• If not accessible, through an intermediary (e.g., representative, guardian, care-giver)
• If neither works, research and define expected users and tasks (make sure you verify with clients and update if needed)
• Broad coverage of possible users
• Typical “expected” users (e.g., regular student for Canvas)
• Occasional but important users (e.g., exchange student/evaluator for Canvas)
• The “unusual/extreme” users (e.g., students who overload their course work, who need special accommodations)

15
 How to Describe A Context?

• Typically through a scenario in describing the activities in a story that allows exploration and discussion of
contexts, needs, and requirements (ID-Book p408). Can be used to:
• Explain user’s goals in a natural way for readers to relate easily
• Provide a fuller picture of the activities, including historical events (that impacts decisions)
• Talk about frustrations, thus lead to potential solutions
• Describe an imaginary situation for future designs (futurist scenarios)

Every university student needs to send emails at some point in their student life, to their peers, advisors,
instructors, …etc. There are different reasons to send an email, for example, to schedule a meeting, to send in
a form, and to ask questions. There are etiquettes they should adhere to. They often draft and attach other
content before they send the email. They typically want to do it fast and hope the recipients will get the email
and respond in a timely manner.They do it anytime of the day with their phone, tablets, and computers.
16
 How to Describe a User?

• Typically through a persona in describing a typical user of the design (ID-Book p403) that are:
• Realistic but not idealized, typically a synthesized version of a number of real users
• Characterized by a unique set of goals relating to the design
• Enriched by details such as behaviour, attitudes, activities, and environment

Ron Smith is a 20-year-old third year university Hermione Doe is a 18-year-old university
student in Computer Science major. He enjoys student in Chemical Engineering major. She is
sports and video games. He wants a balanced an achiever and is very serious about her
study & play life, and be social. To connect with studies and wants to spend most of her time
others he typically call them up or hang out doing school work. Socializing is good but not
with them. her first priority. She uses emails and texts
heavily for communications.
17
 Tips on Creating Good Personas

• Capture user characteristics and synthesize

• Not real people, not idealized
• Bring them to life with bits of a real person
• Name, nickname, physical attributes
• Personal background, hobbies, goals
• Can include stock photos of profile pic and belongings
• There are online tools to generate them (e.g., https://www.hubspot.com/make-my-persona)
• Develop multiple personas
• Cover spectrum of possible users
• Do not stereotype
18
 Do Not Stereotype Users

• Understand your users instead of making assumptions about them

Designing for seniors Designing for gamers

19
 Relationship between Scenario & Personas

• A scenario describes one use of a product (or design) or one example of achieving a goal, while a persona
characterizes a typical user of the product (or design) (ID-Book p414)

20

Source: http://www.smashingmagazine.com/2014/08/06/a-closer-look-at-personas-part-1/
 Using Context & Users to Generate Requirements

Context describes constraints, and implications Users provide insights into their approach, and
for the design to address/adhere to attitude towards an interface
(e.g., emails for school purposes) (e.g., tech-savvy students want to email profs/peers fast)

Needs, Goals, and Priorities

(e.g., able draft, attach, and send proper email)

Design Requirements
(e.g., suggest suitable words)
21
 Break & Activity

• 10 min break – in the mean time, imagine you are designing a mobile interface for a language learning app
• There are 2 groups of users: (1) children, (2) adults
• Come up with a context for each group, then a persona for each group

• 10 min when back – design the interface based on what you come up
• What would you show first? What kind of instructions will you provide? In what form?
• Share your design sketch with your classmates, explain

22
Task-Centered Design

Another way to generate requirements

(and later help creating tasks for evaluation)

23
 Tasks

• Activities that need to be accomplished (by a user)

• Typically in a hierarchical structure consisting of tasks and sub-tasks
• Example: task: send an email ➔ sub-tasks: specify recipient, write
subject, write message, add attachments (optional), send content
• Described by
• Who is doing it
• Frequency & importance
• Prerequisites & consequences
https://xkcd.com/1425/
24
 What Can We Learn about Tasks?

• Current tasks with existing the interface/system

• How are things being done
• Challenges & work-arounds
• “Wishlist” tasks
• Tasks that users want to complete but can’t with the existing interface/system
• “Envisioned” tasks
• Tasks that can be done with a new interface/system

25
 Where Can We Learn about Tasks?

• Similar to understanding users, but focus on how they carry out their tasks
• Ideally through direct contact (e.g., same company, company being consulted)
• If not accessible, through an intermediary (e.g., representative, guardian, care-giver)
• If neither works, research and define expected tasks (make sure you verify with clients and update if needed)

• Observe how users do their tasks, ask them what work and not work for them
• Can also consult other stakeholders (e.g., supervisors, sponsors), ask them what they envision
• …more in the next lecture

26
 Hierarchical Task Analysis

• Involves breaking a task down into sub-tasks, then sub-sub-tasks and so on

• First start with the high-level task (typically a verb-noun phrase)
• Then sub-divide into lower-level sub-tasks (typically a step to accomplish the parent task)

• Focuses on physical & observable actions, including those that are not directly related to
software or interaction device
• For example, “write message” doesn’t specify which software to use or what kind of input

27
 Describing A Task – Example

Start
• Overall task: Send an email
• User: Student
Specify recipient
• Pre-requisite: Student already logged in the email client, internet connection stable
• Sub-task 1 – Specify recipient Write message
• Sub-task 2 – Write subject
• Sub-task 3 – Write message Add attachments
• Sub-task 4 – Add attachments
• Sub-task 5 – Send content Send contents
• Consequence: Email being sent to recipient, a copy automatically added to “sent” folder
End

28
 Describing A Task – Example (cont’d)

• Because of the way sub-tasks are listed, we can have variations of the overall task
• Example 1 (typical): 1-2-3-4-5
• Example 2 (no-attachment): 1-2-3-5
• Example 3 (multiple-attachments): 1-2-3-4-4-4-5
• Example 4 (missing recipient, error): 2-3-4-5
• …etc.
• A good task description should describe a complete activity

29
 Tasks Collection

• Who is doing it X Frequency & Importance

• Routine & important tasks • Routine & important tasks

• Routine but unimportant tasks • Routine but unimportant tasks
• Infrequent but important tasks • Infrequent but important tasks
• Infrequent & unimportant tasks • Infrequent & unimportant tasks
Instructor Students

Scope narrowed down to instructors Scope narrowed down to students

Instructor: routine & important tasks Students: routine & important tasks
Instructor: infrequent but important tasks Students: infrequent but important tasks
30
 Evaluating Tasks

• Make sure the tasks are actionable, realistic, and complete

• Circulate descriptions to users, rewrite if needed
• Pay attention to omissions pointed out, corrections, clarifications, suggestions
• Users are not always right or accurate
• They might not be able to anticipate new technologies
• They might have their own bias or habits
• Task analysis should help to tease out the actual need to accomplish the activities

31
 Exercise

• You are commissioned to design a new alarm clock

• What are the tasks?
• Can you break them down into sub-tasks?

• Make sure the tasks are actionable, realistic, and complete

32
 Summar y

• Identifying Contexts & Users

• contexts describe the situation or environment that influence decisions, thus impose constraints and implications to the
design for it to adhere to
• users describe the people who carry out tasks and make decisions, thus provide insights into their approach and attitude
towards an interface and what affects their judgments
• Task-Centered Design
• to describe tasks in a systematic and hierarchical way
• help generate requirements that guide the design, and tasks for evaluation

33
 Post-Lecture Activity

• Read/watch these (and those in the slides)

• Chapters 11 of ID-Book: Discovering Requirements
• Chapter 5 of the UX book: Extracting Interaction Design Requirements
https://sfu-primo.hosted.exlibrisgroup.com/permalink/f/15tu09f/01SFUL_ALMA51189030600003611
• A Closer Look at Personas
http://www.smashingmagazine.com/2014/08/06/a-closer-look-at-personas-part-1/
• How to do a research interview
https://www.youtube.com/watch?v=9t-_hYjAKww

34