User and Task Analysis

Identifying user goals and the work that supports them

Dr. Bill Gribbons

Bentley University
User Experience Program
wgribbons@bentley.edu
April 2016
Session Goals
• Make the case for conducting user research
• Define user personas and determine goals (value focus for each)
• Redefine the problem space
• Determine the alignment of user and business goals
• Align business, user, regulatory, and technical requirements
• Identify, document and manage tension and conflict
• Define the task and information structure that support goals
• Understand the rapid task analysis concept and supporting data
collection methods
• Move from data to insight, then design
• Move beyond status quo to product innovation

2 Gribbons © 2016
Section One
Defining the task (work or process) analysis
A Practical Definition

A research process that enables designers and developers to

better understand the user’s goals, tasks that support these
goals, task structure, task flexibility, information
requirements, language support, the role of the user, and
work that can be automated through system design.
Ultimately, the task analysis strives to improve human
productivity, enhace product loyalty, reduce errors, shorten
learning requirements, reduce mental workload and
enhance the quality of the user experience.
When this analysis is properly executed, overall system
complexity is generally reduced.

4 Gribbons © 2016
In a perfect world…
Regulatory
Requirements

Technical Task workload consistent with goals

Business Requirements and perceived value
Goals
Alignment

Alignment Value
Alignment Task Proposition
Requirements

Alignment
User
Goals User Abilities
And
Expectations

5 Gribbons © 2016
Business Goal or User Goal?

Did a driver wake up one morning

and scream
“I’ve always dreamed of pumping
my own gas!”

6 Gribbons © 2016
Justifying Analysis
You must manage the politics of change and loss of control
With Analysis
• Up-front resources
• Less rush to development
• Research expertise
• Access to customers /users
• Need to re-shape development
process
• External, customer
centered/balanced input
• Heavy first-time costs produce
long-term return on investment
7 Gribbons © 2016
Without Analysis
• Heavy costs found in
development and support
• Functionality, information and
complexity creep
• Development driven
• Increase need for training and
external support
• Contact with customers late in
process through beta testing
and client support
• Internal, analyst, developer or
SME control
Justification

• 65-70% of software lifecycle costs occur in

the maintenance phase
• 80% of these costs are due to unmet or
unforeseen user requirements
• Revision is 1.5 – 6 times greater during
development than during the design phase
and 60-100 times greater after release

8 Gribbons © 2016
Value-added
key performance indicators

• Document value of improvements

 Reduced development costs
 Reduced support costs
 Increased value to client
 Improved user experience
• retention
• passion
• Sales
• onboarding

• Continuous process improvements

• Continuous innovation
• Consistent with “lean” methodologies
9 Gribbons © 2016
Overcoming Resistance

Keep the research:

1. Early and quick

2. Integrated or running in parallel
3. Inexpensive
4. Reusable

10 Gribbons © 2016
Assumptions
• The benefit of the analysis is only as good as the
quality of the data collected (sample and bias).
• Any system can be broken down to smaller and
smaller sub-systems that can then be described
and improved (what is the point of diminishing
returns?)
• The analysis can build a false expectation in the
user group that something will be done, which
may or may not be the case. Lower this
expectation during the research.

11 Gribbons © 2016
Process Overview

2. Define user 4. Define macro

profiles, profile structure of work 6. Allocate task
goals, and process that to user or
business goals supports goals system. Write
requirements
document

1. Preparation 3. Document and 5. Define 7. Post-

define business, micro-level mortem and
technical, view of each mgt of
regulatory work process knowledge
requirements base

12 Gribbons © 2016
Section Two
Preparation, Client Briefing and Problem Definition
Preparation: Informed Design

• Anticipate issues by the characteristics of the

problem, the nature of the task domain
(work/process), and the profiles of the user
population –leverage existing research.
• Use these findings to minimize in-the-field
analysis (cost and time motivation). Consistent with
lean methodologies.

14 Gribbons © 2016
Preparation: targeting business needs
• Liability
• Regulatory
• Past failures
• Shifts in the marketplace
• Market differentiation threats/opportunities
• Slippage in market share
• Problems with development, support and
maintenance
• Migration to new technologies and services (e.g.,
electronic medical record, mobile, social, software as
service, gamification, internet of things)

15 Gribbons © 2016
Additional Sources of Data

• Documentation and training groups

• User/customer support
• Media reports
• Social media – independent of the sponsoring organization
• Customer communities
• Trade shows or their equivalent
• Competitive analysis

16 Gribbons © 2016
Qualities of a good researcher
• A good listener -- careful observer
• Knows when to listen and comfortable with silence
• Hears what the user is “not saying” as well as what they “do say”
• Bias-free (agenda or other motivation)
• Strong inter-personal skills
• Non-threatening and calming
• Applies past experience
• Anticipates problems --Reacts quickly to the situation
• Knows the business
• Recognizes new business opportunities (value and innovation)
• Sensitive to user’s needs, abilities, anxieties, and motivation
(empathy)

17 Gribbons © 2016
Client/Stakeholder Briefing
It’s all about scope and focus whether it’s an internal or external project

• Identify business goals

• Prioritize goals
• Determine technical requirements
• Determine resource allocation
• Build market and user profiles *
• Assign value to profiles *
• Define quality expectations in market (competitive analysis)
• Identify problem areas and hidden costs
• Identify regulatory requirements
• Determine importance of product
• Determine cost of errors
• Determine quality metrics (refined later)

18 Gribbons © 2016
Client briefing:
• Assume some of this data will reveal itself through
dialog
• Remain sensitive to opportunities for future
business opportunities
• Identify political struggles

19 Gribbons © 2016
Problem Definition: Reframing the problem
Are we solving the correct problem?

The case of the “Self-Checkout”

20 Gribbons © 2016
21 Gribbons © 2016
22 Gribbons © 2016
23 Gribbons © 2016
24 Gribbons © 2016
Follow the value captured in users’ goals

25 Gribbons © 2016
Re-think the task
… perhaps make it go away

26 Gribbons © 2016
Exercise 1: Client Requirements
Aging in Place

27 Gribbons © 2016
Section Three
Defining user profiles and goals. Review of data gathering methods

28 Gribbons © 2016
 Striking the Right Balance
What is your product strategy?
When does a product become unwieldy?
When does one product become two?
Should you employ an all-at-once or staged approach?

Everything to everybody Too focused on a narrow market

evaluate on product-by-product basis

• functionality creep • clear sense of priority • limits market growth

and value
• unnecessary features a • inflexible
burden on every user • focused feature
• places heavy burden
development
• inefficient use of on profile definition
development and • reasonable room for
support resources market expansion
• Configurability option

29 Gribbons © 2016
Case Studies
1. Company A: Developed successful customized
applications for individual clients. Saw opportunities and
value in this application for a broader market. Struggles
to force more diverse client needs to a narrowly defined
product core.

2. Company B: Built their success on fulfilling every

functionality request from a diverse range of client sites.
This functionality accumulated over many years to create
a “ bloated monster.” This company woke up one
morning to find the very clients who requested the
functionality in the first place complaining about
functionality creep and poor usability.

30 Gribbons © 2016