Step 3: Verify Your Causes

After identifying potential causes for your pain points, you are now ready to verify these causes. This step is important, since you cannot be sure if your causes are correct. Maybe people will drop your remote control purely due to poor weight distribution of your device, and hence you will not need to use resources on redesigning the keypad layout.

Why change the entire physical design of your device if the problem is purely in the weight distribution? Why redesign an entire application if people only have problems with the wording of one specific function? Fixing nonexistent problems is of course a waste of time, and you may even introduce new pain points or other problems when doing this.

There may be several approaches to verifying your causes, but it is difficult to do without consulting the people who originally stated the pain points. So you will need to approach the users—or at least the user experience experts—that provided you with the pain points.

Simple phone interviews with users may do the trick. Short e-mails asking about the different causes may be another approach. Inviting the users that had pain points for a face-to-face session is a third.

You will need to describe the different causes that you came up with for their pain points, and you can ask the users what they believe is the true cause. Several causes may be true for the same pain point, so also allow the users to give more than one cause. Finally, the users may state that none of the proposed causes are true. In this case you will need to ask further questions of the user to try to find the real causes.

In the TV remote control example, we will assume that the verified causes identified for each of the pain points are as listed in Figure 9-10.

Figure 9-10. Verified causes for the pain points in the remote control example