The UX Book: Agile UX Design for a Quality User Experience

Front Cover
The UX Book: Agile UX Design for a Quality User Experience
Copyright
Dedication
Contents
Preface
"UX" Means User Experience
Goals for This Book
Usability Is Still Important
But User Experience Is More Than Usability
A Practical Approach
Practical UX Methods
From an Engineering Orientation to a Design Orientation
Audiences
Whats Changed Since the First Edition?
New Content and Emphasis
Tightened Up the Verbose Text
A More Relaxed Approach to Grammar and Writing Style
What We Dont Cover
About the Exercises
Team Projects
About the Authors
Acknowledgments
Guiding Principles for the UX Practitioner
Part 1: Introduction
Chapter 1: What Are UX and UX Design?
1.1. The Expanding Concept of Interaction
1.2. Definition of UX
1.2.1. Distinction From ``UI´´
1.2.2. Distinction from ``HCI´´
1.2.3. What Does ``UX´´ Mean?
1.2.4. The Rise of UX
1.2.5. What Is User Experience?
1.2.5.1. Interaction, direct or indirect
1.2.5.2. Totality of effects
1.2.5.3. User experience is felt internally by the user
1.2.5.4. Context and ecology are crucial to user experience
1.3. UX Design
1.3.1. Can a User Experience Be Designed?
1.3.2. Importance of UX Design
1.4. The Components of UX
1.4.1. An Analogy With Fine Dining
1.4.2. Usability
1.4.3. Usefulness
1.4.4. Emotional Impact
1.4.4.1. Why include emotional impact?
1.4.4.2. Deeper emotions
1.4.4.3. Joy, excitement, and fun
1.4.4.4. Attractive designs somehow work better
1.4.4.5. Engagement and enticement
1.4.4.6. Coolness and ``wow´´ in UX design
1.4.4.7. Role of branding, marketing, and corporate culture
1.4.5. Meaningfulness
1.5. What UX Is Not
1.5.1. Not Dummy Proofing or User Friendliness
1.5.2. Not Just About Dressing Things Up in a Pretty Skin
1.5.3. Not Just a Diagnostic View
1.6. Kinds of Interaction and UX
1.6.1. Localized Interaction
1.6.2. Activity-Based Interaction
1.6.3. System-Spanning Interaction
1.6.4. The Dagstuhl Framework of Interaction and UX
1.7. Service Experience
1.8. Why Should We Care? The Business Case for UX
1.8.1. Is the Fuss Over Usability Real?
1.8.2. No One Is Complaining and It Is Selling Like Hotcakes
1.8.3. Cost Justification
Chapter 2: The Wheel: UX Processes, Lifecycles, Methods, and Techniques
2.1. Introduction
2.1.1. Where Are We Heading?
2.1.2. The Need for Process
2.1.3. What Do You Get by Having a Process?
2.2. The Basic Process Components for UX
2.2.1. UX Design Lifecycle
2.2.2. UX Lifecycle Activities
2.2.3. UX Design Lifecycle Process
2.2.4. The Wheel: A Model of the UX Lifecycle
2.2.5. Lifecycle Subactivities
2.2.6. UX Methods
2.2.7. UX Techniques
2.2.8. A Hierarchy of Terms
2.3. The Fundamental UX Lifecycle Activities
2.3.1. The Understand Needs UX Lifecycle Activity
2.3.2. The Design Solutions UX Lifecycle Activity
2.3.2.1. Interpretation of ``design´´: broad versus narrow
2.3.3. The Prototype Candidates UX Lifecycle Activity
2.3.4. The Evaluate UX Lifecycle Activity
2.4. UX Design Techniques as Life Skills
2.4.1. Observation
Exercise 2.1: Make Some Deeper Observations
2.4.2. Abstraction
2.4.3. Note Taking
2.4.4. Data/Idea Organization
2.4.5. Modeling
2.4.6. Storytelling
2.4.7. Immersion
2.4.8. Brainstorming
2.4.9. Sketching and Drawing
2.4.10. Framing and Reframing
2.4.11. Reasoning and Deduction
2.4.12. Prototyping and Envisioning
2.4.13. Critical Thinking
2.4.14. Iteration
2.4.15. UX Techniques Are Used in Combination
2.5. Choosing UX Processes, Methods, and Techniques
2.5.1. The UX Lifecycle Process Choice
2.5.2. The Idea of Appropriating Methods and Techniques
2.5.2.1. Design situations: Dependencies that govern lifecycle activity, method, and technique choices
2.5.2.2. Choosing methods and techniques
2.5.2.3. Mapping project parameters to lifecycle activity, method, and technique choices
Chapter 3: Scope, Rigor, Complexity, and Project Perspectives
3.1. Introduction
3.1.1. Rigor and Scope: Project Parameters that Determine Process Choices
3.2. Rigor in a UX Method or Process
3.2.1. What Is Rigor?
3.2.2. Complexity as an Influence on the Need for Rigor
3.2.2.1. The system complexity space
3.2.2.2. Interaction complexity
3.2.2.3. Domain complexity
3.2.2.4. The system complexity space quadrants
Simple interaction, simple work domain
Complex interaction, complex work domain
Complex interaction, simple work domain
Simple interaction, complex work domain
Gradations within the system complexity space
3.2.3. Domain Familiarity as an Influence on the Need for Rigor
3.2.4. Risk Aversion Influences the Need for Rigor
3.2.4.1. The risk of data loss
3.2.4.2. Risks associated with legal, safety, and compliance constraints
3.2.5. The Stage of Development within Your Project as an Influence on the Need for Rigor
3.2.6. Project Resources: Budgets, Schedules, and/or Personnel Capabilities are Determiners of Rigor
3.2.7. Being Rapid in Lifecycle Activities, Methods, and Techniques
3.2.7.1. Not every project needs rigorous UX methods
3.2.7.2. Rapid methods are a natural result
3.2.7.3. Over time our need for rigor has diminished
3.2.7.4. Rapidness principle: Work as rapidly as you can
3.3. Scope of Delivery
3.4. The Commercial Product Perspective and the Enterprise System Perspective
3.4.1. The Commercial Product Perspective
3.4.1.1. Single-user products
3.4.1.2. Multiuser collaborative products
3.4.2. The Enterprise System Perspective
Chapter 4: Agile Lifecycle Processes and the Funnel Model of Agile UX
4.1. Challenges in Building Systems
4.1.1. Change Happens During a Project
4.1.1.1. Evolution of project requirements and parameters
4.1.1.2. External changes
4.1.2. Two Views of These Changes
4.1.2.1. Reality
4.1.2.2. Designers understanding of these changes
4.1.3. The Gap Between Views
4.1.4. Responding to Change
4.1.5. Closing the Gap
4.1.6. True Usage is the Only Ascertainer of Requirements
4.1.7. Communicating Feedback About Requirements
4.1.7.1. Communication problems on the users side
4.2. The Old Waterfall SE Lifecycle Process
4.2.1. The Waterfall Process was an Early SE Attempt to Get Organized
4.2.2. The Waterfall Process Did Have Some Feedback, But Not the Right Kind
4.2.2.1. Verification and validation of phase work products
4.2.2.2. But this wasnt enough
4.2.2.3. Change discovered was too expensive to address
4.2.2.4. Feedback was not communicated well with respect to user needs
4.2.2.5. The bottom line
4.3. Embracing an Agile Lifecycle Process
4.3.1. Scope and Chunking are Key to Real Usage Feedback
4.3.2. On the UX Side, Weve Always Had a Measure of Agility Without Chunking
4.3.3. But SE Hasnt Had the Luxury of Making User-Facing Prototypes
4.3.4. And SE Wasnt That Interested in Users, Anyway
4.3.5. So Why Have we in UX Followed SE into an Agile Approach?
4.4. The Funnel Model of Agile UX
4.4.1. Why a New Model Was Needed
4.4.1.1. Speed kills: Rapidness and agility are not the same
4.4.1.2. The single biggest problem: UX was expected to follow the agile SE flow completely
4.4.2. Introducing the Funnel Model of Agile UX
4.4.2.1. Scope in the funnel model
4.4.2.2. Speed and rigor in the funnel model
4.4.3. Late Funnel Activities
4.4.3.1. Syncing agile UX with agile SE sprints
4.4.4. Early Funnel Activities
4.4.4.1. The need to establish a conceptual design
4.4.4.2. Small systems with low complexity
4.4.4.3. SE needs a funnel model, too
4.4.4.4. The nexus of early and late parts of the funnel
Chapter 5: Prelude to the Process Chapters
5.1. Introduction
5.2. Intertwining of Processes, Methods, and Techniques
5.2.1. Activity Timing
5.2.2. Can We Describe It that Way in a Book?
5.2.3. Readers Need a ``Pure´´ Description of Each Lifecycle Activity
5.3. A dedicated UX Design Studio, an Essential Tool for Teamwork
5.3.1. Why You Need a UX Design Studio
5.3.2. What You Need in Your UX Design Studio
5.3.3. Dedicated Space
5.3.4. The Virginia Tech Industrial Designs Studio: The Kiva
5.4. The Project Commission: How Does a Project Start?
5.4.1. Key UX Team Roles from the Start
5.4.1.1. Usage researcher
5.4.1.2. UX designer
5.4.1.3. Graphic or visual designer
5.4.1.4. UX analyst
5.4.1.5. Product owner
5.5. The Middleburg University Ticket Transaction Service and the New Ticket Kiosk System
5.5.1. The Existing System: The Middleburg University Ticket Transaction Service (MUTTS)
5.5.1.1. Organizational context of the existing system
5.5.2. The Proposed New System: The Ticket Kiosk System
5.5.3. Rationale
5.6. The Product Concept Statement
5.6.1. Whats in a Product Concept Statement?
5.6.2. Introduction to Process-Related Exercises
Exercise 5.1: Product Concept Statement for a Product or System of Your Choice
5.7. Welcome to the Process Chapters
Chapter 6: Background: Introduction
6.1. This is a Reference Chapter
6.2. Brief History and Roots of HCI and UX
6.2.1. Frederick Winslow Taylor: Scientific Management
6.2.2. Early Industrial and Human Factors Engineering
6.2.3. Dreyfuss, after WW II
6.2.4. Human Factors Meets HCI
6.2.5. Computer Science: Hardware and Software Foundations of Human-Computer Interaction
6.2.6. Changing Concepts of Computing and Interaction
6.2.6.1. Disappearing technology
6.2.6.2. Embedded, ubiquitous, and ambient interaction
6.2.6.3. Situated, embodied, and tangible interaction
6.2.7. Evolving Importance of UX
6.2.7.1. Emerging desire for usability
6.2.7.2. The rise of usability engineering
6.2.7.3. The rise of user experience
6.3. Shifting Paradigms in HCI and UX
6.3.1. Engineering Paradigm
6.3.2. Human Information Processing (HIP) Paradigm
6.3.3. Phenomenological Paradigm
6.3.3.1. Making meaning
6.3.4. All three paradigms have a place in design and development
6.4. Fun Interaction at Work
6.4.1. What about Fun at Work
6.4.2. Fun Can Make Some Work More Interesting
6.4.3. But Fun Can Trade Off with Usability
6.4.4. Fun Is Not Compatible with Some Work Situations
6.5. Who Introduced The Waterfall Model?
6.6. Silos, Walls, and Boundaries
6.6.1. Working in Silos
6.6.2. Throwing it Over the Wall
6.6.3. Many Projects Collapsed Under the Weight
6.6.4. UX Design Suffers
Part 2: Usage Research
Chapter 7: Usage Research Data Elicitation
7.1. Introduction
7.1.1. You Are Here
7.1.2. Usage Research Isnt about Asking Users What They Want
7.2. Some Basic Concepts of Usage Research Data Elicitation
7.2.1. The Concepts of Work, Work Practice, and Work Domain
7.2.2. Understanding Other People's Work Practice
7.2.3. Protecting Your Sources
7.2.4. Not the Same as Task Analysis or a Marketing Survey
7.2.5. Are We Studying an Existing Product/System or a New One?
7.3. Data Elicitation Goals and Our Approach
7.3.1. Eliciting Data to Synthesize a Broad Overall Picture
7.3.2. It Requires Real Detective Work
7.3.3. Tactical Goals
7.3.3.1. Using usage research data rather than opinion
7.4. Before the Visit: Prepare for Data Elicitation
7.4.1. Learn about the Subject Domain
7.4.2. Learn about the Client Company/Organization
7.4.3. Learn about the Proposed Product or System
7.4.4. Decide on Your Data Sources
7.4.4.1. Interview subject-matter experts (SMEs)
7.4.4.2. Use dual experts
7.4.4.3. Listen to focus groups
7.4.4.4. Employ user surveys
7.4.4.5. Do competitive analysis
7.4.4.6. Acquire domain knowledge through education
7.4.4.7. Be your own domain expert
7.4.5. Choose Visit Parameters
7.4.6. Data Elicitation Goals Based on Scope
7.4.7. Organize Your Data Elicitation Team
7.4.8. Recruit Participants
7.4.9. Identify Settings in Which to Study Usage
7.4.10. Establish Need to Observe Users in Their Work Context
7.4.11. Establish Management Understanding of Need to Keep Pressure Off Interviewees and Give Them Freedom to Comment Hon ...
7.4.12. Prepare Your Initial Questions
7.5. During the Visit: Collect Usage Data
7.5.1. Set the Stage Upfront
7.5.2. Interviewing versus Observing: What They Say versus What They Do
7.5.3. Hints for Successful Data Elicitation
7.5.4. Kinds of Information to Look for
7.5.4.1. Specific Information to Look for
User work roles
User persona information
Inputs to user stories
Artifacts of the work practice and how they are used
Flow of information and artifacts
User tasks
Physical work environment
Information architecture
Photo ops
7.5.4.2. General information to look for
Shadowing and the user journey
Activity-based interaction data and the broader ecology
7.5.5. Capture the Data
7.5.6. For High Rigor, Maintain Connections to Data Sources
7.5.7. Writing Good Raw Data Notes
Exercise 7-1: Usage Research Data Elicitation for the Product or System of Your Choice
7.5.8. Getting the Most Out of Data Elicitation
Chapter 8: Usage Research Data Analysis
8.1. Introduction
8.1.1. You Are Here
8.1.2. Overview of Usage Research Analysis Subactivities
8.2. Distill the Essence from Your Usage Research by Synthesizing Work Activity Notes
8.2.1. Work Activity Notes can be Handwritten or Typed into a Laptop
8.2.2. Make Each Work Activity Note Elemental
8.2.3. Make Each Work Activity Note Brief and Concise
8.2.4. Make Each Work Activity Note Complete
8.2.5. Make Each Work Activity Note Modular by Retaining Context
8.2.5.1. Dont use an indefinite pronoun, such as "this," "it," "they," or "them" unless its referent has already ...
8.2.6. Additional Information to Accompany Work Activity Notes
8.2.7. For High Rigor, Maintain Connections to Data Sources
8.2.8. Preview of Sorting Work Activity Notes into Categories
8.3. Extract Work Activity Notes that Are Inputs to User Stories or Requirements
8.3.1. User Stories and Requirements
8.3.2. Extracting Inputs to User Stories or Requirements
8.4. Extract Notes that Are Inputs to Usage Research Models
8.4.1. Modeling Started Back at the Project Beginning
8.5. The Remaining Work Activity Notes Become Inputs to your Method for Organizing the Notes by Category
8.5.1. Print Work Activity Notes
Exercise 8-1: Work Activity Notes for Your Product or System
8.6. Organize the Work Activity Notes
8.6.1. Card Sorting Is a Simple Technique for Data Organization
8.7. For Higher Rigor in Complex Projects, Construct a WAAD
8.7.1. Affinity Diagrams
8.7.2. Prepare Your Work Space and Your Team
8.7.3. Compartmentalize the WAAD, Separating it by User Work Roles
8.7.4. The Bottom-Up Process of WAAD Building
8.7.4.1. Posting work activity notes
8.7.4.2. Labels for groups of notes
8.7.4.3. Growing labels with growing groups
8.7.4.4. Splitting large groups
8.7.4.5. As you work
8.7.5. Use Technology to Support WAAD Building
8.7.6. Continue Organizing Groups into a Hierarchy
8.7.7. At the End, Create "Highlights"
8.7.8. Observations from This Example
8.8. Lead a Walkthrough of the WAAD to Get Feedback
Exercise 8-2: WAAD Building for Your Product or System
8.9. Synthesize the "Elephant" that Is User Work Practice and Needs
Chapter 9: Usage Research Data Modeling
9.1. Introduction
9.1.1. You Are Here
9.1.2. What Are Usage Research Data Models and How Are They Used
9.1.3. Kinds of Data Models
9.1.4. Modeling Should Already be Well Established
9.2. Some General "How to" Suggestions for Data Modeling
9.2.1. How Modeling Can Overlap with Usage Research Data Elicitation and Analysis
9.2.2. For High Rigor, Maintain Connections to Data Sources
9.3. The User Work Role Model
9.3.1. What is a User Work Role?
9.3.2. Subroles
9.3.3. Mediated Work Roles
Exercise 9-1: Identifying User Work Roles for Your Product or System
9.3.4. User Class Definitions
9.3.4.1. Knowledge- and skills-based characteristics
9.3.4.2. Physiological characteristics
Exercise 9.2: User Class Definitions for Your Product or System
9.3.5. Post the Work Role Modeling Results
9.4. User Personas
9.4.1. What Are User Personas?
9.4.2. Extracting Data for Personas
9.4.3. A Preview of How to Create Personas
Exercise 9.3: Early Sketch of a User Persona
9.5. The Flow Model
9.5.1. What Is a Flow Model?
9.5.2. Central Importance of the Flow Model
9.5.3. How to Make a Flow Model
Exercise 9.4: Creating a Flow Model for Your Product or System
9.5.4. The Customer Journey Map, a Kind of Flow Model
9.6. Task Structure Models-The Hierarchical Task Inventory (HTI)
9.6.1. The Task Models
9.6.2. Benefits of a Task Structure Model
9.6.3. Tasks versus Functions
9.6.4. Create an HTI Model
9.6.5. Hierarchical Relationships
9.6.6. Avoid Temporal Implications
9.6.7. HTI Can Often be Decomposed by User Work Role
Exercise 9.5: HTI for Your Product or System
9.7. Task Sequence Models
9.7.1. What Are Task Sequence Models?
Exercise 9-6: Usage Scenarios as Simple Task-Sequence Models for Your Product or System
9.7.2. Components of Task Sequence Models
9.7.2.1. Task and step goals
9.7.2.2. Task triggers
9.7.2.3. Task barriers
9.7.2.4. Information and other needs in tasks
9.7.3. How to Make a Step-by-Step Task Sequence Description
9.7.4. Beyond Linear Task Sequence Models
9.7.5. Essential Use Case Task Sequence Models
Exercise 9.7: Task Sequence Model for MUTTS Ticket Buying
9.7.6. State Diagrams: The Next Step in Representing Task Sequencing and Navigation
9.8. Artifact Model
9.8.1. Whats in an Artifact Model?
9.8.2. Constructing the Artifact Model
9.9. Physical Work Environment Model
9.9.1. Include Hardware Design, When Appropriate
9.9.2. Include Environmental Factors, When Appropriate
9.10. Information Architecture Model
9.11. The Social Model
9.11.1. The Social Model Captures the Culture of the Shared Workplace
9.11.2. Simplified Approach to the Social Model
9.11.3. Identify Active Entities
9.11.4. Identify Kinds of Issues, Pressures, Worries, and Concerns
9.11.5. Add Concerns and Influences to the Social Model List
Exercise 9.8: A Social Model for Your Product or System
Exercise 9.9: A Social Model for Smartphone Usage
9.12. Hybrid Models
9.13. Model Consolidation
9.14. Wrap Up
9.14.1. Barrier Summaries Across All Models
9.14.2. Post Data Models in Your UX Design Studio
Chapter 10: UX Design Requirements: User Stories and Requirements
10.1. Introduction
10.1.1. You are Here
10.1.2. User Stories and Requirements Are About Codifying UX Design Wants
10.1.3. Introduction to User Stories
10.1.4. Introduction to Requirements
10.1.5. Choose the Approach You Need
10.1.6. Requirements in the UX World
10.1.6.1. Requirements as design goals, not constraints
10.1.6.2. UX requirements versus UX design prototypes as SE requirements
10.1.6.3. Software and functional implications of UX design requirements
10.1.7. Formal Requirements are Waning in Popularity
10.2. User Stories
10.2.1. The Truth About User Stories
10.2.1.1. Asking users what they wanted was originally discouraged
10.2.1.2. How can user stories make for complete requirements?
10.2.1.3. Cleaning up the user stories
10.2.2. What is a User Story?
10.2.3. Team Selection
10.2.4. Writing a User Story
10.2.5. Extrapolation Requirements in User Stories: Generalization of Usage Research Data
10.2.6. Organize Sets of User Stories for Use in UX Design
10.2.7. Prioritizing User Stories for Design and Development
10.3. UX Design Requirements
10.3.1. Degree of Formality Can Vary
10.3.2. Team Selection
10.3.3. The Requirements Structure Evolves
10.3.4. Compose Requirements Statements
10.3.5. The Requirement Statement and Requirements Document
10.3.6. Things to Look for in Your Requirements Notes
10.3.6.1. Keep an eye out for emotional impact requirements and other ways to enhance the overall user experience
10.3.6.2. Questions about missing data
10.3.6.3. System support needs
10.3.6.4. Constraints as requirements
Exercise 10.1: Constraints for Your Product or System
Exercise 10.2: Writing Requirement Statements for Your Product or System
10.4. Validating User Stories and Requirements
10.4.1. Coordinating Requirements, Terminology, and Consistency
10.4.2. Take User Stories and Requirements Back to Customers and Users for Validation
10.4.3. Resolve Organizational, Social, and Personal Issues Arising Out of Work Practice Changes
Chapter 11: Background: Understand Needs
11.1. This is a Reference Chapter
11.2. A True Story: Voting Trouble Experienced by a Senior Citizen
11.3. History of Contextual Inquiry
11.3.1. Roots in Activity Theory
11.3.2. Roots in Ethnography
11.3.3. Getting Contextual Studies into HCI
11.3.4. Connections to Participatory Design
11.4. The SSA Model District Office-An Extreme and Successful Example of an Environment for Data Elicitation
11.5. Roots of Essential Use Cases in Software Engineering
Part 3: UX Design
Chapter 12: The Nature of UX Design
12.1. Introduction
12.1.1. You Are Here
12.1.2. Moving Across the Gap from Analysis to Design
12.1.3. Universality of Design and Relationship to Other Fields
12.1.4. Relationship to Design in Architecture
12.1.5. The Interdisciplinary Nature of Design
12.2. What is Design?
12.2.1. Two Ways the Word ``Design´´ is Used
12.2.1.1. Design as a noun
12.2.1.2. Design as a verb
12.3. The Purpose of Design: Satisfying Human Needs
12.3.1. A Pyramid of Human Needs
12.4. Information, Information Design, and Information Architecture
12.4.1. What is Information?
12.4.2. Information Science
12.4.3. Information Architecture
12.4.4. Pervasive IA
12.4.5. Information Architecture is so Much More
12.4.6. Information Design
12.5. Iteration in the Design Creation Sublifecycle
12.5.1. Deciding on the Design Goal
12.5.2. Generative Design Iteration
12.5.3. Conceptual Design Iteration
12.5.4. Intermediate Design Iteration
12.5.5. Detailed Design Iteration
12.5.6. Design Refinement Iteration
12.5.7. SE Implementation
12.5.8. UX Compliance Phase
12.6. Design Lifecycle for the Agile UX Funnel
Chapter 13: Bottom-Up Versus Top-Down Design
13.1. Introduction
13.1.1. You Are Here
13.2. Bottom-Up Design: Designing for Existing Work Practice
13.2.1. Recap of Our Process Steps Thus Far
13.2.2. The Process so far is Bottom Up
13.2.3. Human-Centered Design or User-Centered Design: Common Names for Bottom-Up Design
13.2.4. Designing for Existing Work Practice is Practical
13.2.5. The Role of Biases and Constraints
13.2.5.1. Bias and inertia from existing usage and user preferences
13.2.5.2. Bias and inertia from market success
13.2.5.3. Effects from advances in technology
13.2.6. Bottom-Up Design is Less Likely to Lead to Innovative Possibilities
13.3. Abstract Work Activities
13.3.1. Nature of Work and Work Practice
13.3.2. Abstract Work Activity
13.3.3. Work Activity Instances
13.3.4. Why is it Useful to Start Top-Down Design with Abstract Work Activities?
13.3.4.1. Provide a clearer understanding of the essence of work
13.3.4.2. Illuminate possible design targets
13.4. Top-Down Design: Designing for the Abstract Work Activity
13.4.1. Top-Down Design Goal
13.4.2. Characteristics of Top-Down Design
13.4.3. Top-Down Design is not Always Practical
13.4.4. Easing the Transition for Customers and Users
13.4.5. Hedging Against Risks of Top-Down Design
13.4.6. Extreme Top-Down Design is the Path to Disruptive Design
Chapter 14: Generative Design: Ideation, Sketching, and Critiquing
14.1. Introduction
14.1.1. You Are Here
14.1.2. Preparing for Design Creation: Immersion
14.1.3. The Role of Synthesis
14.1.4. Overview of Generative Design: Intertwining of Ideation, Sketching, and Critiquing
14.2. Ideation
14.2.1. The Creative Role of Ideation in Design
14.2.2. Ideas: The Building Blocks of Design
14.2.2.1. What is an idea?
14.2.3. Ideation Scope
14.2.4. Ideation Informers, Catalysts, and Techniques
14.2.5. Doing Ideation
Exercise 14-1: Ideation About Aircraft Flight Recorders
14.2.6. Ideation Informers
14.2.6.1. User work roles
14.2.6.2. Personas
Exercise 14-2: Creating a User Persona for Your System
14.2.6.3. Flow models and physical models
14.2.6.4. Activity-based interaction and design
14.2.6.5. Task structure and sequence models
14.2.6.6. Artifact model
14.2.6.7. Information architecture model
14.2.6.8. Social models
14.2.6.9. Requirements
14.2.7. Ideation Catalysts
14.2.7.1. The eureka moment
14.2.8. Ideation Techniques
14.2.8.1. Framing and reframing
14.2.8.2. Abstraction: Getting back to the basics
14.2.8.3. Magic wand: Asking "what if?"
14.2.8.4. Incubation
14.2.8.5. Design patterns and experience
14.2.8.6. Traverse the different dimensions of the problem space
14.2.8.7. Seek opportunities for embodied and tangible interaction
14.3. Sketching
14.3.1. Characteristics of Sketching
14.3.1.1. Sketching is essential to ideation and design
14.3.1.2. Sketching is a conversation about user experience
14.3.1.3. Sketching is embodied cognition to aid invention
14.3.2. Doing Sketching
14.3.2.1. Stock up on sketching and mockup supplies
14.3.2.2. Use the language of sketching
14.3.3. Exercise 14-3: Practice in Ideation and Sketching
14.3.4. Physical Mockups as Embodied Sketches
14.4. Critiquing
14.4.1. Include Users in the Critiquing Activity
14.5. ``Rules of Engagement´´ for Ideation, Sketching, and Critiquing
14.5.1. Behave Yourself
14.5.2. Be Aware of Which Mode You Are In
14.5.3. Iterate to Explore
Chapter 15: Mental Models and Conceptual Design
15.1. Introduction
15.1.1. You Are Here
15.1.2. Mental Models
15.2. How a Conceptual Design Works as a Connection of Mental Models
15.2.1. The Ideal Mental Model in Context
15.2.2. The Designers Mental Model in Context
15.2.3. The Users Mental Model in Context
15.2.4. The Conceptual Design as Mapping Between Mental Models
15.3. Design Starts with Conceptual Design
15.3.1. Need for a Conceptual Design Component at Every Level in the User Needs Pyramid
15.3.2. Conceptual Design for Work Practice Ecology: Describing Full Usage Context
15.3.3. Conceptual Design for Interaction: Describing How Users Will Operate It
15.3.4. Conceptual Design in the Emotional Perspective: Describing Intended Emotional Impact
15.3.5. Leveraging Design Patterns in Conceptual Design
15.3.6. Leveraging Metaphors in Conceptual Design
15.3.6.1. Metaphors can cause confusion if not used properly
15.3.7. Conceptual Design for Subsystems by Work Role
Exercise 15.1: Conceptual Design for Your System
Chapter 16: Designing the Ecology and Pervasive Information Architecture
16.1. Introduction
16.1.1. You Are Here
16.2. Designing for Ecological Needs
16.2.1. Ecological Design: Foundational Layer of the Needs Pyramid Often Overlooked
16.2.2. Designing the Ecology is about Usage Context
16.2.3. Pervasive Information Architecture
16.2.4. Ecological Design Spans Multiple Interaction Channels
16.2.5. A Single Platform in an Ecology Can Have Multiple Interaction Channels
16.2.6. For the User, the Entire Ecology Is a Single Service
16.3. Creating an Ecological Design
Exercise 16-1: Conceptual Design for the Ecology of Your System
16.4. Designing an Ecology to Influence User Behavior
16.5. Example: An Ecology for a Smart Shopping Application
16.5.1. Some High-Level Issues
16.5.2. Key Parts of the Design
16.5.3. How it Works
16.5.3.1. Finding things in the store
16.5.4. Impulse Buying
Exercise 16-2: Pursue this SmartKart Design Idea Further
Chapter 17: Designing the Interaction
17.1. Introduction
17.1.1. You Are Here
17.2. Designing for Interaction Needs
17.2.1. Designing for Interaction Needs Is about Supporting Tasks
17.2.2. Different Device Types in the Ecology Require Different Interaction Designs
17.3. Creating an Interaction Design
17.3.1. Start by Identifying All Devices and Their Roles in the Ecology
17.3.2. Proceed with Generative Design
17.3.3. Establish a Good Conceptual Design for the Interaction
17.3.4. Leverage Interaction Design Patterns
17.3.5. Establish the Information Architecture for Each Device
Exercise 17-1: Conceptual Design for Interaction for Your System
17.3.6. Envision Interaction Flows Across Different Devices in the Ecology
17.4. Storyboards
17.4.1. What Are Storyboards?
17.4.2. Storyboards Can Cover All Layers of the Pyramid
17.4.3. Importance of Between-Frame Transitions
Exercise 17-2: Storyboard for Your System
17.5. Wireframes
17.5.1. The Path to Wireframes
17.5.2. What Are Wireframes?
17.6. Intermediate Interaction Design
17.7. Interaction Design Production
Exercise 17-3: Intermediate and Detailed Design for Your System
17.8. Maintain a Custom Style Guide
17.8.1. What is a Custom Style Guide?
17.8.2. Why Use a Custom Style Guide?
17.8.3. What to Put in a Custom Style Guide?
Chapter 18: Designing for Emotional Impact
18.1. Introduction
18.1.1. You Are Here
18.2. Designing for Emotional Needs
18.2.1. What Designing for Emotional Needs Is About
18.2.1.1. What users feel when interacting with the system
18.2.1.2. Distinctiveness is a factor when designing for emotional impact
18.2.2. Designing for Emotional Impact Is Often Neglected But can be a Market Differentiator
18.3. Creating an Emotional Impact Design
18.3.1. Start with Inputs for Emotional Impacts
18.3.2. Conceptual Design for Emotional Aspects
18.3.2.1. Mood boards: Creating a conceptual design for emotional aspects
18.3.3. Intermediate Design for Emotional Impact
18.3.3.1. Define the visual language and vocabulary
18.3.3.2. Define the motion styles and physics of interaction for each design
18.3.3.3. Define the tone of the language to be used in the design
18.3.3.4. Define the audio characteristics to be used in the design
18.3.3.5. Leverage social and psychological aspects in the design
18.3.4. Emotional Impact Design Production
Exercise 18-1: Conceptual Design for Emotional Response for Your System
Chapter 19: Background: Design
19.1. This is a Reference Chapter
19.2. Participatory Design
19.2.1. Overview
19.2.2. History and Origins of Participatory Design
19.2.3. PICTIVE
19.3. Mental models: An Example of How They can Make for Entertainment
Part 4: Prototype Candidate Designs
Chapter 20: Prototyping
20.1. Introduction
20.1.1. You Are Here
20.1.2. Prototyping Intertwines with Other UX Activities
20.1.3. A Dilemma and a Solution
20.1.4. Advantages of Prototyping
20.1.5. Universality of Prototyping
20.1.6. Scandinavian Origins of Prototyping
20.2. Depth and Breadth of a Prototype
20.2.1. Horizontal Prototypes
20.2.2. Vertical Prototypes
20.2.3. Local Prototypes
20.2.4. "T" Prototypes
20.3. Fidelity of Prototypes
20.4. Wireframe Prototypes
20.4.1. What is a Wireframe?
20.4.2. Wireframe Design Elements
20.4.3. Wireflow Prototypes
20.4.3.1. What is a wireflow prototype?
20.4.4. General Process of Representing Interaction
20.4.4.1. Focus on user workflow
20.4.4.2. Represent flow and navigation with state diagrams
20.4.5. Create a Wireframe for Each State
20.5. Build Up Prototypes in Increasing Levels of Fidelity
20.5.1. High-Level Task Context
20.5.2. Very Low-Fidelity Wireframe Sketches to Support Design Idea Exploration in Generative Design
20.5.2.1. The nature of low-fidelity prototypes
20.5.2.2. The first level of fidelity
20.5.2.3. Decks of wireframes
20.5.3. Static Low-Fidelity Wireframes to Summarize and Solidify Design with UX Team
20.5.3.1. Lower fidelity means initial cost effectiveness
20.5.4. Increased Fidelity Wireframes for Subsequent Design Reviews and Walkthroughs
20.5.4.1. Establish a library of templates for interaction objects in your sketching tool
20.5.5. Medium-Fidelity Wireframes with Some Navigational Behavior to Support Early Design Reviews and Walkthroughs
20.5.6. Medium- to High-Fidelity Click-Through Prototypes to Support Empirical Evaluation
20.5.6.1. Include "decoy" user interface objects
20.5.6.2. Make a ``this feature not yet implemented´´ message
20.5.7. Medium- to High-Fidelity Prototypes Refined Through Evaluation and Iteration to Hand Off to Software Developers
20.5.7.1. Do not think the UX team is now done
20.5.8. Visually High-Fidelity Prototypes to Support Graphic Design
Exercise 20-1: Building a Low- to Mid-Fidelity Wireframe Prototype Deck for Your System
20.6. Specialized Prototypes
20.6.1. Physical Mockups for Physical Interactivity
20.6.2. Paper-in-Device Mockup Prototype, Especially for Mobile Applications
20.6.3. Animated Prototypes
20.6.4. Experience Prototyping, the Goal of High-Fidelity Physical Prototyping
20.6.5. "Wizard of Oz" Prototypes
20.7. Software Tools for Making Wireframes
Part 5: UX Evaluation
Chapter 21: UX Evaluation Methods and Techniques
21.1. Introduction
21.1.1. You Are Here
21.1.2. Methods versus Techniques
21.1.3. User Testing? No!
21.1.4. Types of UX Evaluation Data
21.1.4.1. Quantitative versus qualitative data
21.1.4.2. Objective versus subjective data
21.1.5. Formative Evaluation versus Summative Evaluation
21.1.5.1. Formal summative evaluation
21.1.5.2. Informal summative evaluation
21.1.5.3. Engineering UX evaluation: Formative plus informal summative
21.1.6. Our Goal-Oriented Approach
21.2. UX Evaluation Methods
21.2.1. Empirical UX Evaluation Methods
21.2.2. Analytic UX Evaluation Methods
21.2.3. Comparison
21.2.4. Some Specific Empirical UX Evaluation Methods
21.2.4.1. Lab-based evaluation
21.2.4.2. RITE
21.2.4.3. Quasiempirical evaluation
21.2.5. Weaknesses of UX Evaluation Methods
21.2.5.1. Measurability of user experience: A problem on the empirical quantitative side
21.2.5.2. Reliability of UX evaluation methods: A problem on the qualitative side
21.2.6. Some Specific Analytic UX Evaluation Methods
21.2.6.1. Early design reviews and design walkthroughs
21.2.6.2. Expert UX inspection
21.2.6.3. Heuristic evaluation (HE)
21.3. Rigor versus Rapidness in UX Evaluation Methods and Techniques
21.3.1. There Is a Tradeoff between Rapidness and Achievable Rigor
21.3.2. All Methods Can Span a Range of Rigor and Speed
21.3.3. High Rigor Is not Always a Goal
21.3.4. Some Methods were Invented to Favor Rapidness Over Rigor
21.4. UX Evaluation Data Collection Techniques
21.4.1. Quantitative Data Collection Techniques
21.4.1.1. Objective data: User performance measures
21.4.1.2. Subjective data: User questionnaires
21.4.1.3. Warning: Modifying a questionnaire can damage its validity
21.4.2. Qualitative Data Collection Techniques
21.4.2.1. Critical incident identification
21.4.2.2. User think-aloud techniques
21.4.2.3. Codiscovery
21.5. Specialized UX Evaluation Methods
21.5.1. Alpha and Beta Testing and Field Surveys
21.5.2. Remote UX Evaluation
21.5.3. Automatic UX Evaluation
21.6. Adapting and Appropriating UX Evaluation Methods and Techniques
Chapter 22: Empirical UX Evaluation: UX Goals, Metrics, and Targets
22.1. Introduction
22.1.1. You Are Here
22.1.2. Project Context for UX Metrics and Targets
22.2. UX Target Tables
22.3. Work Role and User Classes
22.4. UX Goals
Exercise 22-1: Identify UX Evaluation Goals for Your System
22.5. UX Measures
22.6. Measuring Instruments: Benchmark Tasks
22.6.1. What Is a Benchmark Task?
22.6.2. Selecting Benchmark Tasks
22.6.2.1. Address designer questions with benchmark tasks and UX targets
22.6.2.2. Create benchmark tasks for a representative spectrum of user tasks
22.6.2.3. Start with short and easy tasks and then increase difficulty progressively
22.6.2.4. Include some navigation where appropriate
22.6.2.5. Avoid large amounts of typing (unless typing skill is being evaluated)
22.6.2.6. Match the benchmark task to the UX measure
22.6.2.7. Adapt scenarios or other task sequence representations already developed for design
22.6.2.8. Use tasks in realistic combinations to evaluate task flow
22.6.2.9. Pick tasks where you think or know the design has weaknesses
22.6.2.10. Dont forget to evaluate with your power users
22.6.2.11. To evaluate error recovery, a benchmark task can begin in an error state
22.6.2.12. Consider tasks to evaluate performance in "degraded modes" due to partial equipment failure
22.6.2.13. Dont try to make a benchmark task for everything
22.6.3. Crafting Benchmark Task Contents
22.6.3.1. Remove any ambiguities with clear, precise, specific, and repeatable instructions
22.6.3.2. Tell the user what task to do, but not how to do it
22.6.3.3. Dont use words in benchmark tasks that appear specifically in the UX design
22.6.3.4. Use work context and usage-centered wording, not system-oriented wording
22.6.3.5. Have clear start and end points for timing
22.6.3.6. Keep some mystery in it for the user
22.6.3.7. Annotate situations where evaluators must ensure preconditions for running benchmark tasks
22.6.3.8. Use "rubrics" for special instructions to evaluators
22.6.4. Other Benchmark Task Mechanics
22.6.4.1. Put each benchmark task description on a separate sheet of paper
22.6.4.2. Write a "task script" for each benchmark task
22.6.4.3. How many benchmark tasks and UX targets do you need?
22.6.4.4. Ensure ecological validity
Exercise 22.2: Create Benchmark Tasks and UX Targets for Your System
22.7. Measuring Instrument: User Satisfaction Questionnaires
22.8. UX Metrics
22.9. Baseline Level
22.10. Target Level
22.11. Setting Levels
22.11.1. Setting the Baseline Level
22.11.2. Setting the Target Level
22.11.3. A Few Additional Targets
22.12. Observed Results
Exercise 22-3: Creating Benchmark Tasks and UX Targets for Your System
22.13. Practical Tips and Cautions for Creating UX Targets
22.14. Rapid Approach to UX Goals, Metrics, and Targets
Chapter 23: Empirical UX Evaluation: Preparation
23.1. Introduction
23.1.1. You Are Here
23.1.2. A Plan for the Empirical UX Evaluation Session
23.2. Evaluation Scope and Rigor
23.2.1. Evaluation Scope
23.2.2. Evaluation Rigor
23.3. Goals for an Empirical UX Evaluation Session
23.4. Select Team Roles
23.4.1. Participation and Buy-In
23.4.2. Facilitator
23.4.3. Prototype Executor
23.4.4. Quantitative Data Collectors
23.4.5. Qualitative Data Collectors
23.4.6. Supporting Actors
23.5. Prepare an Effective Range of User Tasks
23.5.1. Benchmark Tasks to Generate Quantitative Measures
23.5.2. Unmeasured Tasks
23.5.3. Exploratory Free ``Use´´
23.5.4. User-Defined Tasks
23.6. Recruit Participants
23.6.1. Establish Budget and Schedule for Recruiting User Participants Upfront
23.6.2. Identify the Right Kinds of Participants
23.6.2.1. ``Expert´´ participants
23.6.3. Determine the Right Number of Participants
23.6.4. Consider Recruiting Methods and Screening
23.6.5. Use a Participant Recruiting Database
23.6.6. Decide on Incentives and Remuneration
23.6.7. Dont Give Up on Difficult-To-Find User Participants
23.6.8. Recruit for Codiscovery
23.6.9. Manage Participants as Any Other Valuable Resource
23.6.10. Select Participants for Subsequent Iterations
23.7. Prepare for the Session
23.7.1. Lab and Equipment
23.7.2. Session Parameters
23.7.2.1. Task and session lengths
23.7.2.2. Number of full lifecycle iterations
23.7.3. Informed Consent
23.7.3.1. Informed consent permission application
23.7.3.2. Informed consent form
23.7.4. Other Paperwork
23.7.4.1. Nondisclosure agreements (NDAs)
23.7.4.2. Questionnaires and surveys
23.7.4.3. Data collection forms
23.7.5. Training Materials
23.7.6. The UX Evaluation Session Work Package
Exercise 23-1: Empirical UX Evaluation Preparation for Your System
23.7.7. Do Final Pilot Testing: Fix Your Wobbly Wheels
Chapter 24: Empirical UX Evaluation: Data Collection Methods and Techniques
24.1. Introduction
24.1.1. You Are Here
24.1.2. Empirical Ways of Generating and Collecting Data Within the Needs Pyramid
24.1.2.1. Empirical methods and techniques for generating and collecting UX evaluation data in the ecological layer
24.2. Empirical Methods and Techniques for Generating and Collecting Qualitative UX Data
24.2.1. Critical Incident Identification
24.2.1.1. What is a critical incident?
24.2.1.2. Mostly used as a variation
24.2.1.3. Who identifies critical incidents?
24.2.2. Critical Incident Data Capture
24.2.2.1. Whats in critical incident data?
24.2.2.2. Avoid video recording
24.2.2.3. Manual note taking for critical incident data collection
24.2.2.4. Follow up on hunches
24.2.3. The Think-Aloud Data Collection Technique
24.2.3.1. Why use the think-aloud technique?
24.2.3.2. How to manage the participant in the think-aloud technique
24.2.3.3. Codiscovery think-aloud techniques
24.2.3.4. Does thinking aloud affect quantitative task performance metrics in empirical evaluation?
24.3. Empirical Methods and Techniques for Generating and Collecting Quantitative UX Data
24.3.1. Objective Quantitative Data for User Performance Measurement
24.3.1.1. Timing task performance
24.3.1.2. Counting user errors
24.3.1.3. What generally does not count as a user error?
24.3.2. Subjective Quantitative Data Collection: Questionnaires
24.3.2.1. Questionnaires as supplements to lab-based sessions
24.3.2.2. Questionnaires as an evaluation method on their own
24.3.2.3. Semantic differential scales
24.3.2.4. The Questionnaire for User Interface Satisfaction (QUIS)
24.3.2.5. The System Usability Scale (SUS)
24.3.2.6. The Usefulness, Satisfaction, and Ease of Use (USE) questionnaire
24.3.2.7. Other questionnaires
24.3.2.8. Modifying questionnaires for your evaluation
24.3.2.9. Modifying the Questionnaire for User Interface Satisfaction
24.3.2.10. Modifying the System Usability Scale
24.3.3. Methods and Techniques for Generating and Collecting Emotional Impact and Meaningfulness Data
24.3.4. The Most Important Technique: Direct Observation
24.3.5. Verbal Self-Reporting Techniques for Collecting Emotional Impact Data
24.3.5.1. Using the think-aloud technique to evaluate emotional impact
24.3.5.2. Questionnaires as a self-reporting technique for collecting emotional impact data
24.3.5.3. The AttrakDiff questionnaire as a verbal self-reporting technique for collecting emotional impact data
24.3.5.4. Scoring ATTRAKDIFF questionnaires
24.3.5.5. Alternatives to AttrakDiff
24.3.6. Direct Detection of Physiological Responses as Indicators of Emotional Impact
24.3.7. Generating and Collecting Meaningfulness Evaluation Data
24.3.7.1. Long-term studies to evaluate meaningfulness
24.3.7.2. Goals of meaningfulness data collection techniques
24.3.7.3. Direct observation and interviews in simulated real usage situations
24.3.7.4. The importance of self-reporting
24.3.7.5. Periodic questionnaires to sample meaningfulness
24.3.7.6. Diary-based self-reporting by users
24.3.7.7. Voicemail to capture user reports
24.3.7.8. Evaluator-triggered reporting to control timing
24.4. Procedures for Empirical Data Collection Sessions
24.4.1. Preliminaries with Participants
24.4.1.1. Introduce yourself and the lab: Be sure participants know what to expect
24.4.1.2. Paperwork
24.4.2. Session Protocol and Your Relationship with Participants
24.4.2.1. Your attitude toward UX problems
24.4.2.2. Cultivating a partnership with participants
24.4.3. Prepare Yourself for Evaluating with Low-Fidelity Prototypes
24.4.4. The Data Collection Session
24.4.4.1. The session begins
24.4.4.2. Interacting with participants during the session
24.4.4.3. To help the participant or not to help the participant?
24.4.4.4. Keeping your participant at ease
24.4.5. Wrapping Up an Evaluation Session
24.4.5.1. Postsession probing via interviews and questionnaires
24.4.5.2. Reset for the next participant
24.5. Rapid Empirical Methods for Generating and Collecting Qualitative UX Evaluation Data
24.5.1. The Rapid Iterative Testing and Evaluation (RITE) UX Evaluation Method
24.5.1.1. Introduction
24.5.1.2. How to do it: The RITE UX evaluation method
24.5.1.3. Variations in RITE data collection
24.5.2. Quasiempirical UX Evaluation
24.5.2.1. Introduction to quasiempirical UX evaluation
24.5.2.2. Preparing for a quasiempirical evaluation session
24.5.2.3. Conduct a quasiempirical session, collecting data
Exercise 24-1: Empirical UX Evaluation Data Collection for Your System
Chapter 25: Analytic UX Evaluation: Data Collection Methods and Techniques
25.1. Introduction
25.1.1. You Are Here
25.1.2. Adding Analytic Methods to the Mix
25.1.3. Criticism of Analytic Methods
25.2. Design Walk-Throughs and Reviews
25.2.1. Design Walk-Throughs
25.2.2. Design Reviews
25.2.3. Prepare for a Design Review
25.2.4. Conduct a Design Review Session
25.2.5. After the Session
25.3. Focus Groups
25.4. Expert UX Inspection
25.4.1. What is UX Inspection?
25.4.2. Inspection is a Valuable Tool in the UX Toolbox
25.4.3. How Many Inspectors are Needed?
25.4.4. What Kind of Inspectors are Needed?
25.5. Heuristic Evaluation, a UX Inspection Method
25.5.1. Introduction
25.5.1.1. The heuristics
25.5.1.2. The procedure
25.5.1.3. Documenting UX problems
25.5.1.4. Variations abound
25.5.1.5. Limitations
25.6. Our Practical Approach to UX Inspection
25.6.1. The Knock on Your Door
25.6.2. Guided by Insight and Experience
25.6.3. Use a Codiscovery or Team Approach in UX Inspection
25.6.4. Explore Systematically With a Rich and Comprehensive Usage-Oriented View
25.6.5. Inspection is Driven by Tasks and by the Design Itself
25.6.6. Analytic UX Evaluation in the Layers of the Needs Pyramid
25.6.7. Ecological-Layer Inspection
25.6.8. Interaction-Layer Inspection
25.6.9. Emotional-Layer Inspection
Exercise 13-1: UX Inspection of Your System
Chapter 26: UX Evaluation: Data Analysis
26.1. Introduction
26.1.1. You Are Here
26.2. Analyze Quantitative Data
26.2.1. Use Simple Descriptive Statistics
26.2.2. Treat Subjective Quantitative Questionnaire Data as Simply as Possible
26.2.3. Lining Up Your Quantitative Ducks
26.2.3.1. Filling in the "observed results"
26.2.3.2. Filling in the "meet target?" column
26.2.4. The Big Decision: Can We Stop Iterating?
26.2.4.1. Convergence toward a quality user experience
26.3. Analyze Qualitative UX Data
26.3.1. Overview
26.3.2. Analysis Preparation Steps
26.3.2.1. Keep a participant around to help with early analysis
26.3.2.2. Multiple sources of raw UX data
26.3.2.3. Clean up the raw data before your memory fades
26.3.3. Qualitative UX Data Analysis Steps
26.3.3.1. Gather up your raw qualitative UX data notes
26.3.3.2. Extract elemental data notes: Each refers to just one problem
26.3.3.3. Edit raw UX data notes into UX problem descriptions
26.3.3.4. Consolidate congruent data notes
26.3.3.5. Group related UX problem descriptions to be fixed together
26.3.3.6. Usage research analysis tools work here, too
26.3.3.7. Higher level common issues within groups
26.3.4. UX Problem Data Management
26.3.5. Rapid Qualitative Data Analysis
26.4. Cost-Importance Analysis: Prioritizing Problems to Fix
26.4.1. Problem
26.4.2. Importance to Fix
26.4.2.1. Importance rating adjustments
26.4.3. Solutions
26.4.4. Cost to Fix
26.4.4.1. Cost values for problem groups
26.4.4.2. Calibration feedback from down the road: Comparing actual with predicted costs
26.4.5. Priority Ratio
26.4.6. Priority Rankings
26.4.7. Cumulative Cost
26.4.8. The Line of Affordability
26.4.9. Drawing Conclusions: A Resolution for Each Problem
26.4.10. Special Cases
26.4.10.1. Tie-breakers
26.4.10.2. Cost-importance analysis involving multiple problem solutions
26.4.10.3. Problem groups straddling the line of affordability
26.4.10.4. Priorities for emotional impact problems
26.4.11. Rapid Cost-Importance Analysis
26.5. Feedback to the Process
26.6. Lessons From the Field
26.6.1. Onion-Layers Effect
26.6.2. UX Problem Data as Feedback to Process Improvement
Exercise 26-1: UX Data Analysis for Your System
Chapter 27: UX Evaluation: Reporting Results
27.1. Introduction
27.1.1. You Are Here
27.1.2. Importance of Quality Communication
27.1.3. Participant Anonymity
27.2. Reporting Different Kinds of Data
27.2.1. Reporting Informal Summative Results
27.2.1.1. What if you need to convince the team to fix the problems?
27.2.2. Reporting Qualitative Results-The UX Problems
27.2.2.1. Common Industry Format for reporting
27.3. Report Audiences
27.3.1. Reporting to Inform Your Project Team
27.3.1.1. Convey UX problem results clearly
27.3.1.2. Meet with UX team and software developers in person
27.3.2. Explaining UX Evaluation to Stakeholders
27.3.3. Reporting to Inform and/or Influence Management
27.3.4. Reporting to Customer or Client
27.4. Report Content
27.4.1. Individual Problem Reporting Content
27.4.2. Give Some Coverage of the Ecological and Emotional Layers of the Needs Pyramid
27.4.3. Include Cost-Importance Data
27.5. Report Mechanics
27.5.1. Consistency Rules
27.5.2. Reporting Vocabulary
27.5.2.1. Precision and specificity
27.5.2.2. Jargon
27.5.3. Report Tone
27.5.3.1. Respect feelings
27.5.3.2. Accentuate the positive and avoid blaming
27.5.4. Reporting on Large Amounts of Qualitative Data
27.5.5. Your Personal Presence in Reporting
Exercise 27-1: UX Evaluation Reporting for Your System
Chapter 28: Background: UX Evaluation
28.1. This is a Reference Chapter
28.2. The Dangers of Trying to (or Even Appearing to) do FORMAL Summative Evaluation in UX Practice
28.2.1. Engineering Versus Science
28.2.2. What Happens in Engineering Stays in Engineering
28.3. UX Evaluation Reliability
28.3.1. Individual Differences Naturally Cause Variations in Results
28.3.2. Why So Much Variation? UX Evaluation is Difficult
28.3.3. "Discount" UX Evaluation Methods
28.3.3.1. What is a "discount" UX evaluation method?
28.3.3.2. Criticism of discount methods
28.3.3.3. Real limitations
28.3.3.4. But do less rigorous methods work?
28.3.3.5. Be practical
28.3.3.6. Sometimes you do have to pay more to get more
28.3.3.7. At the end of the day, discount methods are the way forward
28.4. Historical Roots for UX Metrics and Targets
28.5. The Early A330 Airbus-An Example of the Need for Ecological Validity in Testing
28.6. Determining the Right Number of Participants
28.6.1. How Many are Needed? A Difficult Question
28.6.2. Rules of Thumb Abound
28.6.3. An Analytic Basis for the Three-To-Five-Users Rule
28.6.3.1. The underlying probability function
28.6.3.2. The old balls-in-an-urn analogy
28.6.3.3. Participant detection rates
28.6.3.4. Cumulative percentage of problems to be found
28.6.3.5. Marginal added detection and cost-benefit
28.6.3.6. Assumptions do not always apply in the real world
28.7. Historical Roots of the Critical Incident Technique
28.7.1. Critical Incident Techniques Started Long Ago in Human Factors
28.7.2. Mostly Used as a Variation
28.7.3. Who Identifies Critical Incidents?
28.7.4. Timing of Critical Incident Data Capture: The Evaluator's Awareness Zone
28.8. Other Methods for Identifying Emotional Response to UX Designs
28.8.1. Direct Observation of Physiological Responses as Indicators of Emotional Impact
28.8.2. Biometrics to Detect Physiological Responses to Emotional Impact
28.8.3. The HUMAINE Project-Physiological Techniques for Affective Measurements
28.9. Nielsen and Molich's Original Heuristics
28.10. UX Problem Data Management
Part 6: Connecting Agile UX with Agile Software Engineering
Chapter 29: Connecting Agile UX With Agile Software Development
29.1. Introduction
29.1.1.1. Agility is not (just) about being fast
29.1.2. Dont Practice Agility Blindly
29.2. Basics of Agile SE Methods
29.2.1. Goals and Principles of Agile SE
29.2.2. Contrasting With the Waterfall Method
29.2.2.1. Operating in Silos
29.2.3. Characteristics of Agile SE Methods
29.2.3.1. Avoiding big design upfront
29.3. Lifecycle Aspects of Agile SE
29.3.1. Planning in Agile SE Methods
29.3.1.1. Customer stories
29.3.1.2. Story-based planning
29.3.1.3. Managing customer stories and development tasks
29.3.1.4. Controlling scope
29.3.2. Sprints in Agile SE Methods
29.3.2.1. Acceptance test creation
29.3.2.2. Unit code test creation
29.3.2.3. Implementation coding
29.3.2.4. Code testing
29.3.2.5. Regression testing
29.3.2.6. Acceptance testing and deployment
29.4. Challenges of Agile SE Methods from the UX Perspective
29.5. What is Needed on the UX Side
29.6. Problems to Anticipate
29.6.1. UX and SE Dont Always Work Together the Way They are Supposed To
29.6.2. The Need for a Full Overview: The Software Side Versus the UX Side
29.7. A Synthesized Approach to Integrating Agile UX and Agile SE
29.7.1. Integrating UX into Planning
29.7.1.1. Small upfront analysis and design
29.7.1.2. UX role helps customer write user stories
29.7.1.3. The truth about user stories
29.7.1.4. UX role helps customer prioritize user stories
29.7.2. Integrating UX into Sprints
29.7.3. Synchronizing the Two Agile Workflows
29.7.3.1. Dove-tailed work activities
29.7.3.2. The value of early delivery
29.7.3.3. Continuous delivery
29.7.3.4. The importance of regression testing
29.7.3.5. Planning across iterations
29.7.3.6. Communication during synchronization
Part 7: UX Affordances, the Interaction Cycle, and UX Design Guidelines
Chapter 30: Affordances in UX Design
30.1. Introduction
30.1.1. Acknowledgement of Source
30.1.2. The Concept of Affordance
30.1.3. The Importance of Affordance Issues in UX Design
30.1.4. Demystifying Affordances
30.1.5. Five Different Kinds of Affordance in UX Design
30.2. Cognitive Affordances
30.2.1. Introduction
30.2.1.1. Definition of cognitive affordance
30.2.1.2. Starring role in UX design for new users
30.2.1.3. How do users acquire cognitive support information?
30.2.1.4. The meaning of cognitive affordances as found in shared conventions
Exercise 30-1: Understanding Meaning Based on Cultural Conventions
30.2.2. Cognitive Affordance Design Issues
30.2.2.1. Cognitive affordance to get the user started
30.2.2.2. Cognitive affordance to help users avoid task completion errors
30.2.2.3. False cognitive affordances misinform and mislead
30.3. Physical Affordances
30.3.1. Introduction
30.3.1.1. Definition of physical affordance
30.3.1.2. Starring role in UX design for experienced or power users
30.3.1.3. Some physical affordances are better than others; some depend on the user
30.3.1.4. Physical affordances for opening doors
30.3.1.5. Physical devices can also offer cognitive affordance
30.3.1.6. Physical devices can also offer emotional affordance
30.3.2. Physical Affordance Design Issues
30.3.2.1. Helping user manipulate objects, do actions
30.3.2.2. Physical disabilities
30.3.2.3. Physical awkwardness
30.3.2.4. Physicality
30.3.2.5. Manual dexterity and Fitts law
30.3.2.6. Physical overshoot
Exercise 30-2: Other Examples of Physical Overshoot
30.4. Sensory Affordance
30.4.1. Introduction
30.4.1.1. Definition of sensory affordance
30.4.2. Visual Sensory Affordance Design Issues
30.4.2.1. Visibility
30.4.2.2. Noticeability
30.4.2.3. Discernibility
30.4.2.4. Text legibility
30.4.2.5. Distinguishability
30.4.2.6. Color
30.4.2.7. Presentation timing
30.4.3. Auditory Sensory Issues
30.4.4. Haptic and Tactile Sensory Issues
30.5. Functional Affordance
30.5.1. Definition of Functional Affordance
30.6. Emotional Affordance
30.6.1. Definition of Emotional Affordance
30.6.2. Affordances to Support Meaningfulness
30.7. Putting Affordances Together in Design
30.7.1. Affordance Roles-An Alliance in Design
30.7.2. A UX Design Checklist of Affordances
Exercise 30-3: Affordance Design Checklist
30.8. User-Created Affordances as a Wake-Up Call to Designers
Chapter 31: The Interaction Cycle
31.1. Introduction
31.1.1. What is the Interaction Cycle?
31.1.2. Need for a Theory-Based Conceptual Framework
31.2. Norman's Stages-of-Action Model of Interaction
31.2.1. Gulfs between User and System
31.2.1.1. The gulf of execution
31.2.1.2. The gulf of evaluation
31.2.2. From Normans Model to Our Interaction Cycle
31.2.2.1. Partitioning the model
31.2.2.2. Adding outcomes and system response and emphasizing translation
31.3. Interaction Cycle Categories of UX Design Issues
31.3.1. Planning (Design Helping User Know What to Do)
31.3.2. Translation (Design Helping User Know How to Do Something)
31.3.3. Physical Actions (Design Helping User Do the Actions)
31.3.3.1. Physical actions-concepts
31.3.4. Outcomes (Internal, Invisible Effect/Result within System)
31.3.5. Assessment (Design Helping User Know If Interaction Was Successful)
31.3.5.1. Example: Creating a business report as a task within the interaction cycle
31.4. Cooperative User-System Task Performance within the Interaction Cycle
31.4.1. Primary Tasks
31.4.2. Path Variations in the Interaction Cycle
31.4.3. Secondary Tasks, Intention Shifts, and Stacking
Chapter 32: UX Design Guidelines
32.1. Introduction
32.1.1. Scope and Universality
32.1.2. Some of Our Examples Are Intentionally Old
32.2. Using and Interpreting UX Design Guidelines
32.3. Human Memory Limitations
32.3.1. Short-Term or Working Memory
32.3.1.1. Chunking
32.3.1.2. Stacking
32.3.1.3. Cognitive load
32.3.1.4. Recognition versus recall
32.3.1.5. Shortcuts
32.3.2. Other Kinds of Human Memory
32.3.2.1. Sensory memory
32.3.2.2. Muscle memory
32.3.2.3. Long-term memory
32.4. Review of the Interaction Cycle Structure
32.5. Planning
32.5.1. Clear System Task Model for User
32.5.2. Planning for Efficient Task Paths
32.5.3. Progress Indicators
32.5.4. Avoiding Transaction Completion Slips
32.6. Translation
32.6.1. Existence of Cognitive Affordance
32.6.2. Presentation of Cognitive Affordance
32.6.2.1. Cognitive affordance visibility
32.6.2.2. Cognitive affordance noticeability
32.6.2.3. Cognitive affordance legibility
32.6.2.4. Cognitive affordance presentation complexity
32.6.2.5. Cognitive affordance presentation timing
32.6.2.6. Cognitive affordance presentation consistency
32.6.3. Content and Meaning of Cognitive Affordance
32.6.3.1. Clarity of cognitive affordances
32.6.3.2. Precise wording
Data value formats
32.6.3.3. Distinguishability of choices in cognitive affordances
32.6.3.4. Consistency of cognitive affordances
32.6.3.5. Controlling complexity of cognitive affordance content and meaning
32.6.3.6. Likely user choices and useful defaults
32.6.3.7. Supporting human memory limitations in cognitive affordances
32.6.3.8. Cognitive directness in cognitive affordances
32.6.3.9. Complete information in cognitive affordances
32.6.3.10. User/usage centeredness in cognitive affordances
32.6.3.11. Avoiding errors with cognitive affordances
32.6.3.12. Cognitive affordances for error recovery
32.6.3.13. Cognitive affordances for modes
32.6.4. Task Structure
32.6.4.1. Human working memory loads in task structure
32.6.4.2. Design task structure for flexibility and efficiency
32.6.4.3. Grouping for task efficiency
32.6.4.4. Task thread continuity: Anticipating the most likely next step or task path
32.6.4.5. Not undoing user work
32.6.4.6. Keeping users in control
32.7. Physical Actions
32.7.1. Sensing Objects of Physical Actions
32.7.1.1. Sensing objects to manipulate
32.7.1.2. Sensing objects during manipulation
32.7.2. Help User in Doing Physical Actions
32.7.2.1. Awkwardness and physical disabilities
32.7.2.2. Manual dexterity and Fitts law
32.7.2.3. Constraining physical actions to avoid physical overshoot errors
32.7.2.4. Haptics and physicality
32.8. Outcomes
32.8.1. System Functionality
32.8.2. System Response Time
32.8.3. Automation Issues
32.9. Assessment
32.9.1. System Response
32.9.2. Assessment of System Feedback
32.9.3. Existence of Feedback
32.9.4. Presentation of Feedback
32.9.4.1. Feedback visibility
32.9.4.2. Feedback noticeability
32.9.4.3. Feedback legibility
32.9.4.4. Feedback presentation complexity
32.9.4.5. Feedback timing
32.9.4.6. Feedback presentation consistency
32.9.4.7. Feedback presentation medium
32.9.5. Content and Meaning of Feedback
32.9.5.1. Clarity of feedback
32.9.5.2. Precise wording
32.9.5.3. Completeness of feedback
32.9.5.4. Tone of feedback expression
32.9.5.5. Usage centeredness of feedback
32.9.5.6. Consistency of feedback
32.9.5.7. User control over feedback detail
32.9.6. Assessment of Information Displays
32.9.6.1. Information organization for presentation
32.9.6.2. Visual bandwidth for information display
32.10. Overall
32.10.1. Overall Simplicity
32.10.2. Overall Consistency
32.10.2.1. Structural consistency
32.10.2.2. Consistency is not absolute
32.10.2.3. Consistency can work against innovation
32.10.3. Reducing Friction
32.10.4. Humor
32.10.5. Anthropomorphism
32.10.5.1. Avoiding anthropomorphism
32.10.5.2. The case in favor of anthropomorphism
32.10.6. Tone and Psychological Impact
32.10.7. Use of Sound and Color
32.10.8. Text Legibility
32.10.9. User Preferences
32.10.10. Accommodation of User Differences
32.10.11. Helpful Help
32.11. Conclusions
Chapter 33: Background: Affordances, the Interaction Cycle, and UX Design Guidelines
33.1. This is a Reference Chapter
33.2. A Little History of the Concept of Affordances
33.3. Confusion Over Affordances in Early HCI/UX
33.4. Examples of How Cognitive Affordances can be Informed by Shared Cultural Conventions
33.5. How Functional Affordances Fit in with Gibsons Ecological View
33.6. Where Did UX Design Guidelines Come from?
Parting Thoughts
References
Index
Back Cover