The problem I have with UCD and CDD is not the methods. The problem is that people so often misunderstand them. People hear “user centered” and think, for some insane reason, that we are encouraging them to turn their entire design process over to the user. They hear “listen to your customer” and think that we want them to blindly accept every ridiculous feature request made by somebody with a credit card and an opinion.
Guess what? I rarely speak for entire communities of people, but I think I can safely say that nobody in the user centered design or customer driven development business are asking that of anybody. If they are, they’re idiots and shouldn’t be listened to anyway.
Unfortunately, a lot of us have debunked this myth by explaining that we don’t actually think that customers can predict future behavior (even their own) or that they’re going to have some grand design vision for your product. We just think that customers are great at talking about their problems and pain points, and that those are good things for you and your designers to know when you create a new feature or product.
I’m suggesting that we come up with a new name that will be harder (or at least more fun) to misinterpret: Pain Driven Design.
What Is Pain Driven Design (PDD)?
The PDD methodology requires that, before you start 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 to make that pain go away by some brilliant method of your devising. You then check to make sure you made their pain go away without causing them any more pain.Is There a Clever Analogy?
There is! Imagine you’re a doctor. You want to help people feel better. The first thing you need to do is to talk to patients who come to see you. Now, of course, you’re not going to ask them what disease they have and how they think you should treat it. You’re going to ask them, “Where does it hurt?” You’re probably going to also ask them a lot of other questions about how they normally feel, what their medical history is, what their family is like, and other things like that. You’ll probably also, if you’re a good doctor, examine them, double check their reported symptoms, and check for symptoms they may not even know they have.Then, when you have figured out what is causing them pain, you will determine a good course of treatment that is likely to work based on your knowledge of various diseases, your extensive medical training, other work in the field, and how the patient reacts to treatments. You will then closely monitor their progress and adjust your approach as necessary.
Pain Driven Design is a lot like that. You will talk to your users and potential users and find out what causes them pain when they are trying to solve a problem. You will interview them about their habits, likes, and dislikes. You will observe them using the product or competitors' products and look for commonly appearing symptoms. You will then decide how to go about curing their pain. And, of course, you will closely monitor all of your users to see how they respond to your treatment. Since you have a large number of users, and there aren’t any pesky rules against human experimentation in this context, you will run tests to see which treatment performs best.
Does It Work Before I Have a Product?
Sure it does! Presumably, your eventual product will solve somebody’s problem, yes? Maybe their problem is that it is too hard to find a great restaurant while traveling or that they are sort of bored while waiting for the train. OK, those don’t seem like big problems, but they are problems nonetheless and should have solutions.Since you don’t have a product yet, you need to figure out how people are currently solving this problem. Are they using a similar product? A completely different one? Are they simply suffering in silence without even knowing that their lives would be infinitely better if this problem would go away?
You can find these things out by asking people about how they’re dealing with their problems and what the pain points are with their current solutions (or non-solutions). You can learn more about their pain by watching them suffer through it. Don’t worry, it’s not so bad to watch them suffer, because you know your product will help them!
What If I Already Have a Product?
It still works! You see, no matter how much you love your product, unless it’s perfect, it’s causing pain to somebody. I’m sure it’s not on purpose. You’re not a monster. But something about your product is confusing or hard to use, and it’s driving at least one of your customers nuts.Again, examine them. Find out when they feel the most pain while using your product. Watch brand new people use your product to see how much pain it takes to learn. Watch old customers use your product to figure out what weird workarounds they've created to avoid the pain that you’re causing them.
Find all the pain points. Then come up with devastatingly clever ways to fix them.
What If My Product Is Disruptive?
It's still solving a problem, right? Even if it's solving that problem in a completely novel way or solving it for a new group of users, presumably if people are going to adopt the product, the product will be solving a particular problem for them.That’s great . Even if people have never seen anything like your product, you can get a huge amount of information by talking to users about how they currently solve their problems as well as their general environment for problem solving. And once your disruptive product has been launched, chances are it’s causing some people some pain, so you should observe people interacting with it to learn where the pain points are.
What If My Customers Try to Tell Me How to Fix Their Problems?
Well, I suppose you could plug your ears and scream loudly so that you won’t be in danger of hearing them talk about their solutions. Or you could listen to their solutions and then politely follow up to make sure you understand the underlying pain that they’re trying to cure. Frankly, I prefer the latter approach, but it’s up to you.One interesting thing that I’ve found in my many, many years of listening to customers is that sometimes the customers are right about the solution. I know, crazy! I mean, we've been assured by hundreds of people that listening to customers' solutions is completely useless and that they're always wrong! Guess what? They're not. This doesn’t mean you should take their word as gospel, but I can't imagine that people within your company have a patent on coming up with the right solutions to customer problems. Just because an idea for a solution comes from a user doesn’t automatically make it useless or wrong, even if the anti-UCD crowd seems to think so.
How Will Pain Driven Development Be Misinterpreted?
Who can say? I sort of hope somebody reads only the title of this post and writes a scathing retort about how I’m a horrible person for advocating that designers be subjected to pain until they come up with better designs (note: they shouldn’t, except in certain very specific cases, and they know who they are). Or maybe they’ll dissect my doctor/patient analogy and point out all the ways in which it’s flawed (note: there are 17 ways. See if you can spot them all!) and thereby conclude that, since my analogy isn’t perfect, my methodology must also be crap.But I hope a few people will say, “Hey, that Pain Driven Design methodology is just a catchy name for understanding our customers’ problems so that we can come up with better solutions!” And more importantly, I hope a lot of people will say, “You know, that Pain Driven Design sounds like a great idea, and we should try it in our organization!”
Like the post? You could leave me a message in the comments, tweet about this post, read some of my other posts, tweet about them, or hire me to help you learn how to find your customers' pain points! Those are all valid options.
You should also follow me on Twitter.