You are previewing User-Centered Design.

User-Centered Design

Cover of User-Centered Design by Travis Lowdermilk Published by O'Reilly Media, Inc.
  1. Dedication
  2. Special Upgrade Offer
  3. Preface
    1. Is This Book Right for Me?
    2. Conventions Used in This Book
    3. Using Code Examples
    4. Safari® Books Online
    5. How to Contact Us
    6. Acknowledgments
      1. People Who Helped Me Write This Book
      2. People Who Helped Me with Life
  4. 1. Our World Has Changed
  5. 2. What Is User-Centered Design?
    1. UCD Is Not Usability
    2. UCD Is Not Subjective
    3. UCD Is Not Just Design
    4. UCD Is Not a Waste of Time or Money
    5. UCD Is Not a Bug Report
    6. UCD Is Not a Distraction
  6. 3. Working with Users
    1. What If I Don’t Have Access to Users?
      1. Knowing When to Listen to Users and When to Not
    2. Dealing with Different Types of Users
      1. The Information Overloader
      2. The Control Freak
      3. The Devil’s Advocate
    3. Dealing with Negativity
  7. 4. Having a Plan
    1. How Do I Know Which Plan Is Right for Me?
    2. Creating a Team Mission Statement
    3. Defining Your Project
    4. Collecting User Requirements
    5. Creating Functional Requirements
    6. Documenting Data and Workflow Models
    7. Documenting Prototypes
    8. Reviewing Your Documentation
  8. 5. Creating a Personal Manifesto
    1. Exercising Restraint
    2. Building a Narrative
    3. Creating Personas
    4. Creating Scenarios
  9. 6. Creativity and User Experience
    1. Having User-Experience Goals
    2. Creativity Requires Courage and Hard Work
      1. Pick Up a Pencil
      2. Creative Freedom
      3. Understanding Your Goal
      4. Steal (I Mean Borrow) from Others
    3. Creativity Requires Questioning
  10. 7. Design Principles
    1. Principle of Proximity (Gestalt Principle)
    2. Visibility, Visual Feedback, and Visual Prominence
    3. Hierarchy
    4. Mental Models and Metaphors
      1. Progressive Disclosure
      2. Consistency
      3. Affordance and Constraints
      4. Confirmation
      5. Hick’s Law
      6. Fitt’s Law
  11. 8. Gathering Feedback
    1. How Many Users Will I Need?
    2. Surveys
    3. Conducting Interviews
    4. Task Analysis
    5. Heuristic Evaluation
    6. Storyboarding
    7. Using Prototypes
    8. A/B Testing
  12. 9. Usability Studies
    1. What Are Usability Studies?
    2. Creating a Testing Plan
      1. Introduction
      2. Reassurance
      3. Testing Guidelines
      4. Tasks
      5. Conclusion
      6. Thanks
    3. What You’ll Need
      1. Stopwatch
      2. Notepad
      3. Environment
      4. Spreadsheet or Database
      5. Cameras or Audio Recording
    4. Conducting the Study
    5. Don’t Hesitate to Practice
    6. Compiling Your Findings
  13. 10. You’re Never Finished
    1. It’s Impossible to Get It Right the First Time
    2. Be Prepared to Reboot
    3. Final Thoughts
  14. 11. Other Resources
    1. Twitter
    2. Tools for Prototyping
    3. Websites
  15. A. Sample Project Template
    1. Template
    2. Project Title
      1. Software Development Life Cycle Project Template
      2. Software Development Life Cycle Summary
      3. Project Details
      4. User Requirements
      5. Specifications Sheet (Functional Requirements)
      6. Data and Workflow Models
      7. Data Processes
      8. Prototypes
      9. Maintenance Notes
    3. Example Persona
      1. Dan Welks
    4. Sample Script for a Usability Study
      1. Introduction to Study
  16. B. References
  17. Index
  18. About the Author
  19. Colophon
  20. Special Upgrade Offer
  21. Copyright

Chapter 8. Gathering Feedback

“Millions saw the apple fall, but Newton was the one who asked why.”

Bernard Mannes Baruch

It’s time to go out into the world and find out what users really think about the applications we make for them. We need to ask detailed questions and open ourselves to criticism that may be difficult to hear. We have to observe users and document our findings in order to gain an overall understanding of what works and what doesn’t.

Receiving criticism is not fun. If anyone has told you they enjoy getting feedback on their work, that person is lying. Being told you missed something, made a mistake, or went in the wrong direction essentially means you’re not finished. It means you have more work to do. It means you’re not perfect.

I’m not going to tell you to enjoy criticism. I’m not going to say you should shout with glee at the thought of redesigning an application or that you should do a happy dance when you realize you’ll have to recode a complex function.

The truth is that we all want to hit a home run. We want to show our new application to users, clients, friends, and family and be told we’ve nailed it: we got everything right, we’re done, and we did it all on version 1.0.

Here’s what I will suggest: we have to learn to be tolerant of feedback. The best developers I know have a desire to get things right, no matter the consequence. Above all else (sleep, money, or ego), they want to build the best application possible. They realize that receiving honest, quality ...

The best content for your career. Discover unlimited learning on demand for around $1/day.