Announcing The User Experience Team of One (2nd edition)!

Frequently Asked Questions

These common questions and their short answers are taken from Tomer Sharon’s book Validating Product Ideas: Through Lean User Research . You can find longer answers to each in your copy of the book, either printed or digital version.

  1. What is lean user research?
    Lean user research is a discipline that provides insights into users, their perspectives, and their abilities to use products and then gives this information to the right people at the right time so that the research is invaluable for developing products. Lean user research focuses on answering three big questions about people: What do people need? (See Chapter 1.) What do people want? (See Chapter 5.) Can people use the thing? (See Chapter 6.)
  2. How is lean user research different than “regular” user research?
    Lean user research is mostly conducted by non-researchers who have burning questions about their audience (or potential audience). They want to answer these questions quickly, effectively, and on their own without hiring a professional. Lean user research is not perfect and can be at times quick and dirty, meaning some corners are cut. For example, since non-researchers might not have very good control of their body language, lean user research calls for more indirect approaches to learning. It values remote techniques over in-person ones (see Chapters 7 and 8).
  3. Does this book include everything I need to know about user research?
    No! This is a book for product developers and managers who are not skilled researchers. Therefore, research techniques are described in a relatively prescribed manner, skipping underlying factors, options, and dilemmas. The goal here is to help non-skilled product developers to do their own far-from-being-perfect-yet-effective research. If you want to learn more about research techniques described in this book, there are multiple excellent resources available. These are listed on the companion website at leanresearch.co.
  4. I prefer to spend three free hours on writing more code rather than reading yet another book. If I only have time to read one chapter, which one should I read?
    The short answer is Chapter 3 “How Do People Currently Solve a Problem?”
    The long answer is read the introduction first and then the table of contents, and see if any of the chapters discusses a burning question you might have right now. If so, read that chapter first. I recommend reading Chapter 3 regardless, because observation, the research technique described there, is a fundamental tool about learning from users.
  5. Should I read this book cover to cover?
    No! This is a “doing,” not a “reading” book. The best way to digest the content of the book is to first scan it to identify a burning question (or questions) you (or your team) currently have. Then access the relevant chapter, read its premise, roll up your sleeves, and start going through the steps while completing the activities described in them. Reading about these activities won’t get you anywhere. As Ric Flair used to say, “To be the man, you have to beat the man.” Or if you are not a pro-wrestling fan, “If you want to shoot, shoot. Don’t talk!”
  6. UX is about designing interfaces. Does this book include guidance on that?
    Heck, no! UX is about so many things: user interface, interaction design, user research, information architecture, visual design, content strategy, and more. This book includes tons of advice about user research; however, it will not help you with guidance on how to design screens and wireframes. Some of the chapters will help you get insights about your screen design (for example, Chapter 6) or your product’s information architecture (Chapter 8), but there aren’t any design guidelines in here.

back to Validating Product Ideas