دسترسی نامحدود
برای کاربرانی که ثبت نام کرده اند
برای ارتباط با ما می توانید از طریق شماره موبایل زیر از طریق تماس و پیامک با ما در ارتباط باشید
در صورت عدم پاسخ گویی از طریق پیامک با پشتیبان در ارتباط باشید
برای کاربرانی که ثبت نام کرده اند
درصورت عدم همخوانی توضیحات با کتاب
از ساعت 7 صبح تا 10 شب
دسته بندی: برنامه نويسي ویرایش: 2 نویسندگان: Rex Hartson. Pardha S. Pyla سری: ISBN (شابک) : 0128053429, 9780128053423 ناشر: Morgan Kaufmann سال نشر: 2018 تعداد صفحات: 918 زبان: English فرمت فایل : PDF (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) حجم فایل: 98 مگابایت
کلمات کلیدی مربوط به کتاب کتاب UX: طراحی Agile UX برای یک تجربه کاربری با کیفیت: طراحی، تجربه کاربر، چابک، نیازمندی های نرم افزار، مدل سازی داده ها، تست قابلیت استفاده، چرخه عمر توسعه نرم افزار، داستان های کاربر، قابلیت استفاده، طراحی UX، تحقیقات استفاده، ارزیابی UX
در صورت تبدیل فایل کتاب The UX Book: Agile UX Design for a Quality User Experience به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.
توجه داشته باشید کتاب کتاب UX: طراحی Agile UX برای یک تجربه کاربری با کیفیت نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.
رشته طراحی تجربه کاربر (UX) به یک عمل مطمئن تبدیل شده است و این نسخه منعکس کننده این تکامل است و در برخی زمینه ها تسریع می کند. از نظر فنی، این نسخه دوم کتاب UX است، اما بسیاری از آن جدید هستند و بیشتر شبیه یک دنباله هستند. یکی از گرایشهای مثبت عمده در UX، تأکید مداوم بر طراحی است - نوعی طراحی که مهارتها و بینشهای خلاقانه طراح را برجسته میکند و ترکیبی از فناوری را با قابلیت استفاده، سودمندی، زیباییشناسی و معنادار بودن برای کاربر تجسم میدهد. در این نسخه یک چارچوب طراحی مفهومی جدید از بالا به پایین برای کمک به خوانندگان با این تکامل معرفی شده است. کل این نسخه به سمت یک فرآیند چرخه عمر UX چابک، که در مدل قیفی چابک UX توضیح داده شده است، به عنوان تطبیق بهتری با رویکرد چابک استاندارد کنونی مهندسی نرمافزار طراحی شده است. برای انعکاس این روندها، حتی عنوان فرعی کتاب به «طراحی UX چابک برای تجربه کاربری با کیفیت» تغییر یافته است. این کتاب که به عنوان یک کتاب راهنما و راهنمای میدانی برای متخصصان UX و یک کتاب درسی برای دانش آموزان مشتاق طراحی شده است، همراه با تمرینات درون کلاسی و پروژه های تیمی است. این رویکرد به جای رسمی یا نظری، عملی است. هدف اصلی هنوز هم ایجاد درک درستی از تجربه کاربری خوب و چگونگی دستیابی به آن است. برای خدمت بهتر به این امر، فرآیندها، روشها و تکنیکها در مراحل اولیه معرفی میشوند تا مفاهیم مرتبط با فرآیند را به عنوان زمینهای برای بحث در فصلهای بعدی ایجاد کنند.
The discipline of user experience (UX) design has matured into a confident practice and this edition reflects, and in some areas accelerates, that evolution. Technically this is the second edition of The UX Book, but so much of it is new, it is more like a sequel. One of the major positive trends in UX is the continued emphasis on design―a kind of design that highlights the designer’s creative skills and insights and embodies a synthesis of technology with usability, usefulness, aesthetics, and meaningfulness to the user. In this edition a new conceptual top-down design framework is introduced to help readers with this evolution. This entire edition is oriented toward an agile UX lifecycle process, explained in the funnel model of agile UX, as a better match to the now de facto standard agile approach to software engineering. To reflect these trends, even the subtitle of the book is changed to “Agile UX design for a quality user experience. Designed as a how-to-do-it handbook and field guide for UX professionals and a textbook for aspiring students, the book is accompanied by in-class exercises and team projects. The approach is practical rather than formal or theoretical. The primary goal is still to imbue an understanding of what a good user experience is and how to achieve it. To better serve this, processes, methods, and techniques are introduced early to establish process-related concepts as context for discussion in later chapters.
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