This document provides an overview of the user experience design process. It discusses key concepts like human factors engineering, usability, user-centered design, and user experience design. The user experience design process involves gathering user research through contextual inquiry, creating personas and task analyses, designing wireframes and prototypes, testing designs through usability evaluations, and iterating based on user feedback to meet design goals. The overall goal is to understand users and design products that provide a positive experience.

1. ESD Web Team
Mike McCoy
11/15/2010
USER EXPERIENCE DESIGN PROCESS

2. SOME TERMINOLOGY
Ò Human Factors Engineering
Ò Usability
Ò User Centered Design
Ò User Experience Design

3. HUMAN FACTORS ENGINEERING
Ò The Science of Understanding Human:
É Capabilities
É Limitations
É Perception
É Cognition
Ò Using that Data to Design/Engineer:
É Tools
É Systems
É Processes
É Environments
É ‘Experiences’
Ò Roots - WWII Cockpit Design

4. USABILITY
Ò A set of characteristics present in products:
É Ease of use
É Intuitiveness
É Effectiveness
É Learnability
É User Satisfaction
É Aesthetic, Simplicity, Elegance, Coolness, Appeal . . .
Ò Thought leaders in field:
É Identified principles/rules describing characteristics
present in highly usable products (Nielsen, Norman,
Constantine)
É Created methods for engineering/assessing usability
É A method to measure the quality of a user’s
experience with a product – its ‘User Friendliness’.
É Usability Engineering

5. WHY ARE WE STILL HERE?

6. USER CENTERED DESIGN
Ò A design ‘strategy’ from Vredenberg, IBM
Ò Six Principles of User Centered Design:
1. Set Business Goals – target market, intended users, primary
competition
2. Understand Users – driving force behind all design
3. Design the Total Customer Experience – everything they see, hear,
touch is designed together
4. Evaluate Designs – Gather user feedback quickly and vigorously. Use it
to drive and continuously improve product design
5. Assess Competitiveness – Relentlessly focus on the different ways
users currently execute tasks. Design to add value to that.
6. Manage for Users – integrate user feedback into all decision making,
product plans and priorities

7. UCD IN THE HARTFORD’S FRAMEWORK

8. A SAMPLE UCD PROCESS
End User Research
&
Contextual Inquiry
Personas,
Task Analyses
& User Stories
Conceptual Mockups
&
Info Architectures
Usability Evaluation
Interaction Design
Wireframes
&
Prototypes
Scenarios
Iterative,
Participatory Design
Between Product
Team & Users (UCD)

9. USER EXPERIENCE DESIGN
Ò Designing the nature of the experience you want a user to have as
they interact with all aspects of a product and its provider:
É Locating/Purchasing – Web Site Stickiness!!
É Delivery
É Packaging
É Installation
É First Impression
É Learning Curve
É Use
É Support
É Upgrade
É Reuse
Ò “Successful UXD is not just about making easy to use interfaces, it’s
about doing good business.” (Tremaine, Battista)
Ò Is not an attempt to design a subjective experience for users
Ò New focus on balancing user, business, marketing, technology needs

10. USER EXPERIENCE DESIGN PROCESS
Dr. M. Tremaine, R. Battista and Dr. Y. Chen

11. CONTEXTUAL INQUIRY (END USER RESEARCH)
Ò An ethnographic data collection method that
involves observing users in their work setting
É Who are my users? What are their goals, needs?
É What do they need to do with the product?
É What words do they use to name objects in the
their work place?
É What actual tasks they perform (not just what they
say they do)?
É What are their major pain points and roadblocks?
É How can their product or process be improved?

12. CONTEXTUAL INQUIRY - ARTIFACTS
Ò Data collected can be used to produce:
É Personas - Illuminates the users we are designing
for at a low or high level. An abstraction of users.
É Task Analyses – Understand, Map and Optimize
task flow
É Use Cases, Scenarios of Use, User stories -
Integrates well with Agile’s ‘User Stories’.
É Requirements

13. SET DESIGN GOALS - UP FRONT
Ò Negotiated between users and designers.
Ò Objective, measureable (not subjective,
ambiguous)
Ò Identification and Analysis of:
É What users really do, not just what they say they do;
what do they really want?
É How users are likely to use a product (not always how
we envision it)?
É What are the usability needs?
É What are the business’ present and future needs?
É How will this effort impact market position and create
competitive advantage?

14. SET DESIGN GOALS - FOR FINISHED PRODUCT
Ò Business:
É Improve productivity
É Reduce error
É Improve effectiveness
É Reduce training, calls to help desk
É Reduce Development Time and Cost by avoiding unnecessary features,
producing properly conceived ones
Ò End User:
É Reduce stress and fatigue
É Increase job satisfaction
É Motivate and Persuade
É Higher Acceptance
Ò Market:
É Create Pride of Ownership
É Be First to Market
É Create Competitive Advantage
É Maintain/Enhance Reputation

15. DESIGN THE USER INTERFACE
Ò Determine Basic Interface Operation
É Platform – Mobile, Desktop
É Basic Functions
É Are we Going to Copy or Innovate?
Ò Identify Conceptual Model
É Draft Basic Look and Feel
É Matched to User’s Mental Model to Business Model
É Begin Information Architecture
Ò Prioritization and Location of Functions
É What features are built; when (drawn from Goals)
É Determine Screen Flows, Task Flows, Interaction Paradigms

16. DESIGN THE USER INTERFACE - ARTIFACTS
Ò More Terminology . . .

17. DESIGN THE USER INTERFACE - ARTIFACTS
Ò A Mockup:
É Used to ‘sell’ or get
buy-in on an idea.
É Usually full color and
very detailed
É Hint at behavior and
function, but don't
explicitly state it
É Often used for proposing enhancements or new
features

18. DESIGN THE USER INTERFACE - ARTIFACTS
Ò A Wireframe:
É A blueprint or a
schematic that can be
used to help build the
finished product.
É Typically shows several
views of the system
É Is visually a step back
from the mockup

19. MORE ABOUT WIREFRAMES
Ò Used as a basis for a conversation about design direction
Ò Used to answer questions:
É What is the high (or low) level page structure?
É What content will appear on the screen and where?
É What are the organizing principles – task, information architecture, etc?
Ò Used to clarify assumptions
Ò Method can change based on several factors:
É Complexity of problem domain
É Level of assumption
É Magnitude of ‘unknowns’
É Project type - new application vs enhancement
É Expected shelf life
É Business criticality
É Urgency to project
Ò Should use whatever means necessary (low/med/hi fidelity; small or large
scope) to get the point across, have the conversation, answer questions, clarify
assumptions

20. INFORMATION ARCHITECTURES
Ò Based in Library and Information Science.*
Ò An opportunity to analyze the language and concepts
used in the problem domain.
Ò Map out how they interrelate or overlap.
Ò A first step toward establishing the sign posts and
waypoints that will guide a user as they navigate or
‘forage’ through the interactive system (Krug)
Ò Establishes ‘Lay of the Land’
* Is not wireframing, but you can’t wireframe without it

21. INTERACTION DESIGNS & SCREEN FLOWS
Ò Take the wireframe concept a step further – Behavior,
Interaction, Conversation
Ò Used to answer questions about the conversation between
User and System
É What experience does the user have in the language of this conversation?
É What behaviors and interactions are present on the screen (calculations,
input methods, manipulation methods, integration with other screens)
É How will the conversation flow (i.e. can we enumerate the conversation)?
É What interaction design patterns can we use to optimize this
conversation?
Ò These artifacts also change based on context –
complexity, assumption, project type, longevity, business
criticality and urgency

22. EVALUATE THE DESIGN MODEL
Ò Typically Quick and Dirty Methods for Getting
the Low Hanging Fruit:
É Cognitive Walkthroughs
É Heuristic Evaluation – An Expert Review
É User Walkthroughs
É Quick Prototyping (e.g. Axure)

23. BUILD PROTOTYPES
Ò A Prototype:
É A simulation or partially
functional treatment of the
proposed product.
É Some prototypes pursue a
specific use case (weapons
systems); others take a
broader approach (full look
and feel).
É Supports Iterative Testing
and Review
É Retains Buy-In
É Allows you to make
mistakes early and more
inexpensively.

24. TEST PROTOTYPES
Ò Usability Evaluation
É A formal process using representative users in a
simulated, but realistic environment.
É Structured data collection and execution (Task-
Based)
É Captures rich data
Ð Audio, video, interactions
Ð Quantitative Data - Number of Errors, Time on Task
Ð Quantitative Feedback – Likes/Dislikes
É Should be Performed Iteratively
Ò Expert Reviews are still beneficial in this phase

25. PROTOTYPE TEST CLIP 1: COMPLETING A TASK

26. PROTOTYPE TEST CLIP 2: MEETING GOALS

27. PROTOTYPE TEST CLIP 3: PARTICIPATORY DESIGN

28. EVALUATE TEST RESULTS
Ò How well did the prototype perform against
design goals set at start of process?
É Quantitative is best, Qualitative is useful
É Compare the results to a baseline or hypothesis
É Were new issues uncovered?
Ò Determine whether goals were met:
É If goals met: freeze design or negotiate change to
goals (if new problems uncovered)
É If goals not met: change design or negotiate change
in goals (if change is too costly)

29. FINAL THOUGHTS
Ò This process is scalable to the needs and
phase of each project.
Ò Some UX work is better than none at all.
Ò 8-10 users can typically uncover about 90% of
a system’s design and usability flaws. (Source:
Nielsen)