The Pain-Driven Design (PDD) methodology requires that, before you start to design for a product or feature, you need to figure out what is causing pain for your users and potential users. The desired outcome of PDD is, predicting pain, then responding to it. PDD enables organizations’ acquisition of knowledge during the discovery phase. Most successful, mature organizations already follow this approach either directly or indirectly—without knowing it’s a pain-driven design process.
Engineering-dominated organizations obtain feedback from their customers, then implement their customers’ requests. Often, stakeholders become biased by customers’ requests or Support or Sales teams’ feedback from the marketplace.
PDD follows the Lean Startup approach of validating the product early to ensure its success. Both PDD and Lean UX recommend building a hypothesis and validating it with users. However, the key difference between them is the point at which validation occurs. Lean UX teams test their hypothesis through experiments during the course of a sprint cycle. PDD focuses on prediscovery, as Laura Klein suggests in her book UX for Lean Startups. There are many successful examples of teams employing PDD, but the most interesting cases are buffer and Dropbox. Joel Gascoigne, the founder of the buffer, validated his product idea by launching three screens, shown in Figure 7, to understand whether someone would be interested in paying for the idea. He had initially committed to one week and eventually launched the product in seven weeks. You can learn more from Joel Gascoigne’s blog.
Image from The Buffer
A recommended approach to PDD is to focus on problems that are associated with users’ functional jobs rather than on features and functionalities.
Directives of PDD include the following:
Seeking external collaborations within the ecosystem
Pain-driven design and development
Integrating PDD into your development process—breaking down the complexity of pain-driven decision-making into actions lets you articulate the differences between predictable problems and unpredictable pain. Actions for quick turnarounds and building hypotheses include: Understand, Consult, Experiment, Analyze, and Learn. You’ll arrive at a process that is similar to Lean UX, but with the flexibility to modify your actions depending on your decisions.