Module:1 Introduction to User Centered Design

Basics of User Centered Design

 Four basic activities
There are four basic activities in Interaction Design:

– 1. Identifying needs and establishing requirements

– 2. Developing alternative designs

– 3. Building interactive versions of the designs

– 4. Evaluating designs
 A simple interaction design model

Exemplifies a user-centered design approach

 Definition of User-Centered Design (UCD):

•UCD is an iterative
methodology that places the user at
the center of all design decisions.

•It's a design philosophy and

approach that utilizes various
disciplines and design methods to
achieve this user focus
There are four basic activities in the Interaction Design:
 Three key characteristics
• Three key characteristics permeate
these four activities:
– 1. Focus on users early in the design and evaluation
of the artefact
– 2. Identify, document and agree specific usability and
user experience goals
– 3. Iteration is inevitable. Designers never get it right
first time
 Some practical issues
• Who are the users?

• What are ‘needs’?

• Where do alternatives come from?

• How do you choose among

alternatives?
 Who are the users/stakeholders?
• Not as obvious as you think:

— those who interact directly with the product

— those who manage direct users
— those who receive output from the product
— those who make the purchasing decision
— those who use competitor’s products

• Three categories of user (Eason, 1987):

— primary: frequent hands-on
— secondary: occasional or via someone else
— tertiary: affected by its introduction, or will
influence its purchase
 Who are the stakeholders
Check-out operators

• Suppliers
• • Local shop
owners

Customers
 What are the users’ capabilities?
• Humans vary in many dimensions:

— size of hands may affect the size and

positioning of input buttons
— motor abilities may affect the suitability of
certain input and output devices
— height if designing a physical kiosk
— strength - a child’s toy requires little
strength to operate, but greater strength to
change batteries
— disabilities(e.g. sight, hearing, dexterity)
 What are ‘needs’?
• Users rarely know what is possible
• Users can’t tell you what they ‘need’ to help them achieve their goals
• Instead, look at existing tasks:
– their context
– what information do they require?
– who collaborates to achieve the task?
– why is the task achieved the way it is?
• Envisioned tasks:
– can be rooted in existing behaviour
– can be described as future scenarios
 Where do alternatives
come from?
• Humans stick to what they know works

• But considering alternatives is important to ‘break out of the box’

• Designers are trained to consider alternatives, software people generally are not

• How do you generate alternatives?

—‘Flair and creativity’: research and synthesis

—Seek inspiration: look at similar products or look
at very different products
 How do you choose among
alternatives?
• Evaluation with users or with peers, e.g. prototypes
• Technical feasibility: some not possible
• Quality thresholds: Usability goals lead to usability criteria set early on and check
regularly
—safety: how safe?
—utility: which functions are superfluous?
—effectiveness: appropriate support? task coverage,
information available
—efficiency: performance measurements
 Lifecycle models
• Show how activities are related to each other

• Lifecycle models are:

— management tools

— simplified versions of reality

• Many lifecycle models exist, for example:

— from software engineering: waterfall, spiral, JAD/RAD, Microsoft

— from HCI: Star, usability engineering

A simple interaction design model
 Usability engineering lifecycle model
• Reported by Deborah Mayhew

• Important features:
– Holistic view of usability engineering

– Provides links to software engineering approaches, e.g. OOSE

– Stages of identifying requirements, designing, evaluating, prototyping

– Can be scaled down for small projects

– Uses a style guide to capture a set of usability goals

Identifying needs and establishing
requirements
 Overview
• The importance of requirements
• Different types of requirements
• Data gathering
• Task descriptions: Scenarios
Use Cases
Essential use cases
• Task analysis: HTA (Hierarchical Task Analysis (HTA) is a
structured method used to break down tasks into sub-tasks to
understand how users achieve a goal.)
 What, how and why?
• What
– Two aims:
– 1. Understand as much as possible about users, task,
context
– 2. Produce a stable set of requirements

• How:
– Data gathering activities
– Data analysis activities
– Expression as ‘requirements’
– All of this is iterative
 What, how and why?
• Why:
– Requirements definition: the stage where failure
occurs most commonly
– Getting requirements right is crucial
 Establishing requirements
• What do users want? What do users ‘need’?

– Requirements need clarification,

refinement, completion, re-scoping
– Input: requirements document (maybe)
– Output: stable requirements

• Why ‘establish’?

– Requirements arise from understanding

users’ needs
– Requirements can be justified & related to
data
 Different kinds of requirements
• Functional:
—What the system should do
—Historically the main focus of requirements
activities
• (Non-functional: memory size,
response time... )
• Data:
—What kinds of data need to be stored?
—How will they be stored (e.g. database)?
Functional requirements define what a system does, while non-functional requirements define how well the system does
it. Functional requirements specify the features and behaviors of the system,
whereas non-functional requirements dictate the quality attributes and constraints.
Functional Requirements:
•Focus: Specify the core functionalities and features of the system.
•Examples: User authentication, data validation, specific calculations, generating reports.
•Characteristics: Can be easily tested by verifying if the system performs the required actions.
Non-Functional Requirements:
•Focus:
Define the quality attributes of the system, such as performance, security, usability, scalability, and reliability.
•Examples:
Response time, security protocols (like encryption), user interface design, database capacity.
•Characteristics:
Affect the overall user experience and are crucial for system usability and maintainability.
Key Differences in a Table:

Feature Functional Non-Functional

Requirements Requirements
Definition What the system How the system
should do should do it
Focus Features and Quality attributes and
functionality constraints
Examples User login, search Performance,
functionality, data security, usability,
input scalability
Testing Can be tested by Requires testing to
verifying specific assess quality
actions attributes
 Different kinds of requirements
• Environment or context of use:

—physical: dusty? noisy? vibration? light? heat? humidity? ….

(e.g. OMS insects, ATM)
—social: sharing of files, of displays, in paper, across great
distances, work individually, privacy for clients
—organisational: hierarchy, IT department’s attitude and
remit, user support, communications structure and
infrastructure, availability of training
 Different kinds of requirements
• Users: Who are they?
—Characteristics: ability, background,
attitude to computers
—System use: novice, expert, casual,
frequent
—Novice: step-by-step (prompted),
constrained, clear information
—Expert: flexibility, access/power
—Frequent: short cuts
—Casual/infrequent: clear instructions, e.g.
menu paths
 Different kinds of requirements
• Usability:
learnability, throughput, flexibility,
attitude

• Note that user requirements and

usability requirements refer to
different things
User requirements define what users need from a product,
while usability requirements specify how easy and efficient it should be to use the
product to meet those needs. Essentially, user requirements focus on what the product
should do, and usability requirements focus on how it should do it.
User Requirements:
•Definition:
User requirements are the needs, expectations, and desires of the users that a product or system should fulfill.
•Focus:
They are concerned with the functionality, features, and capabilities of the product from the user's perspective.
•Examples:
A user might require a website to allow them to search for products, compare prices, and make purchases.
•Goal:
To ensure the product is useful and meets the users' needs in terms of what it does.
Usability Requirements:
•Definition:
Usability requirements specify how easy and efficient it should be for users to interact with the product to achieve their goals.
•Focus:
They address aspects like learnability, efficiency, memorability, errors, and satisfaction when using the product.
•Examples:
A usability requirement might specify that a user should be able to complete a purchase within a certain number of clicks or that the interface
should be intuitive and easy to learn.
•Goal:
To ensure the product is user-friendly, enjoyable to use, and allows users to achieve their tasks effectively.
 Differences

Feature User Requirements Usability Requirements

Focus What the product should do How easy and efficient it should be to
use

Scope Functionality, features, capabilities Learnability, efficiency, errors,

satisfaction

Example Ability to search for products Completion of purchase in a few clicks

Goal Ensuring the product is useful and meets Ensuring the product is user-friendly
needs and efficient
 Kinds of requirements
• What factors (environmental, user,
usability) would affect the following
systems?

• Self-service filling and payment system

for a petrol (gas) station

• On-board ship data analysis system for

geologists searching for oil

• Fashion clothes website

 Data gathering techniques (1)
• Questionnaires:
—A series of questions designed to elicit
specific information
—Questions may require different kinds of
answers:
simple YES/NO; choice of pre-supplied
answers; comment
—Often used in conjunction with other
techniques
—Can give quantitative or qualitative data
—Good for answering specific questions from
a large, dispersed group of people
 Data gathering techniques (2)
• Interviews:
—Forum for talking to people
—Structured, unstructured or semi-
structured
—Props, e.g. sample scenarios of use,
prototypes, can be used in interviews
—Good for exploring issues
—But are time consuming and may be
infeasible to visit everyone
 Data gathering techniques (3)
• Workshops or focus groups:
—Group interviews
—Good at gaining a consensus view
and/or
highlighting areas of conflict
 Data gathering techniques (4)
• Naturalistic observation:
—Spend time with stakeholders in their
day-to-day tasks, observing work as it
happens
—Gain insights into stakeholders’ tasks
—Good for understanding the nature and
context of the tasks
—But, it requires time and commitment
from a member of the design team, and
it can result in a huge amount of data
—Ethnography is one form
 Data gathering techniques (5)
• Studying documentation:
—Procedures and rules are often written
down in manuals
—Good source of data about the steps
involved in an activity, and any
regulations governing a task
—Not to be used in isolation
—Good for understanding legislation, and
getting background information
—No stakeholder time, which is a limiting
factor on the other techniques
•
 Choosing between techniques
• Data gathering techniques differ in two ways:
– 1. Amount of time, level of detail and risk
associated with the findings
– 2. Knowledge the analyst requires
• The choice of technique is also affected by the kind of task to be
studied:
—Sequential steps or overlapping series of
subtasks?
—High or low, complex or simple
information?
—Task for a layman or a skilled practitioner?
 Problems with data gathering (1)
• Identifying and involving stakeholders:
users, managers, developers, customer reps?,
union reps?, shareholders?
• Involving stakeholders: workshops, interviews,
workplace studies, co-opt stakeholders onto
the development team
• ‘Real’ users, not managers:
traditionally a problem in software
engineering, but better now
 Problems with data gathering (2)
• Requirements management: version control, ownership
• Communication between parties:
—within development team
—with customer/user
—between users… different parts of an organisation use
different terminology
• Domain knowledge distributed and implicit:
—difficult to dig up and understand
—knowledge articulation: how do you walk?
• Availability of key people
 Problems with data gathering (3)
• Political problems within the
organisation

• Dominance of certain stakeholders

• Economic and business environment

changes

• Balancing functional and usability

demands