book a treatment center over the Internet the same way they would book a hotel room. He heard directly from the potential customers what he initially didn’t want to believe: booking a treatment center was just too much of a highly emotional decision to be done entirely online. Here’s a pro tip: Don’t build your product’s UX around a value proposition unless you have tangible evidence that people will want the product! If you are a problem solver (which is instinctual for UX designers, product makers, and entrepreneurs), this process at first feels backward. That’s because it is. We are reverse-engineering the solution to validate the assumptions about the customers and their problem. This approach is particularly important for those of you who have produced dozens of products, including ones that have been very successful. Don’t believe your own hype. Instead, approach every new product or project like an experiment. As I mentioned in the Preface, I’ve been a part-time college professor for more than 20 years. I have always run my courses the same way. The first week, the students have to think of problems they would like to try to solve using technology. Each week, they build toward the final course project, which is to pitch a real product that they’ve tested using the methods I’m teaching you in this book. In the spring of 2014, I offered UX apprenticeships to my students Bita and Ena to take on the “Airbnb for Weddings” product vision. I’m going to present their methods and results to show how you can give any value proposition a real shot to see if it is viable. This was their first assignment: the provisional persona. Step 3: Create provisional personas based on your assumptions Personas can be a helpful tool in giving stakeholders and the product team an empathetic sense of what the end user’s needs, goals, and motivations are. In this way, they can make a product more “user-friendly.” However, the concept of provisional personas has had a tumultuous history with advocates on both sides of the table, so I’m going to give you a little lesson on it to explain why I’m using them here and now. In the early days of software design, the engineers who developed and programmed the products were also typically the designers of the product interfaces. These product interfaces were rarely “user-friendly,” because they were not tested on the end user of the product. Too often, interfaces were pasted together in a hurried fashion to meet a shipping date.