I Hear Voices! … Tips for Turning VOC into Good Design
So often when we have product, service, process, or system failures, we find that the root cause is a lack of connection to what the customer really cares about . Voice of the Customer (VOC). Everyone sees the disconnect, agrees it is the problem, and now sets about obtaining VOC. Now, things really get complicated for when you seek VOC you discover many voices struggling to be heard. The challenge becomes to sift through all those competing voices and understand which are critical and what they are saying before trying to convert what youre hearing into a design or redesign.
So, in an effort to help sort through all of this, there are some simple but very important concepts that can be used to put some structure around all those voices you hear when you set about gathering VOC and converting that information for use in design.
- Direct v. Indirect When gathering customer information within your organization, make sure you distinguish between direct and indirect voices. A direct voice is feedback coming from the end customer. Indirect voices are the customer facing parts of your organization that theoretically act as a proxy for the external end customer. Indirect voices are important as they represent can provide meaning to what you hear from the external end customer. BUT, they are not the end customer voice. Both direct and indirect are important, and are very different.
- Customer Requirements v. Product Requirements Recognize when you are hearing a customer requirement or a product requirement. A customer requirement is usually framed within the context of what the customer experiences while a product requirement is usually a key function or feature of the product. I want a comfortable ride on my bicycle is a customer requirement. I want a big soft seat is a product requirement even if its direct feedback from the customer. When a customer gives you a product requirement, you must ask WHY? before designating it as a desirable product requirement to be used in designing a solution.
- Qualitative v. Quantitative Qualitative feedback is rich but expensive to get so it is normally provided from a smaller customer base. Quantitative feedback can be easily obtained from a large population at a significantly lower cost but it is far less descriptive. The answer is not to solely rely on one or the other. Use interviews to define your survey or your survey to define your script and interview population. Go back and forth taking advantage of the deep aspects of one and the breadth of the other.
- Segmentation Always segment but segment in whatever way is meaningful to your product, service, process or system. As an example, in designing an internal software application many designers look at the functional departments that are going to use the system. But you may find it more meaningful to segment according to the type of usage irrespective of functional area.
- Basic v. Performance v. Excitement Applying the concepts of the Kano model are invaluable. You must know what are basic, performance and excitement levels and their marginal returns as they all would receive different priorities depending on your objectives. The nature of the requirement becomes especially useful when you sort it by demographic or customer segment.
a short intro to QFD and how it can be used to create linkage between customer and technical requirements.
After you have sorted, ranked and prioritized your assembled customer information, it is time to compare and rank product characteristics relative to the customer information. This can be done in a planning matrix (see downloadable PowerPoint document). The planning matrix can then be used to develop design alternatives. The design alternatives can be ranked and rated against both the product requirements to determine process and production feasibility and versus the customer requirements to determine impact to the customer. The two exercises can then be brought together to choose a design which factors in the value, cost, and feasibility of solutions.
It is incredibly valuable to have VOC information. It is even more valuable if you understood how you got it and how you plan on using it. Knowing the end game can also help you determine how you want to gather information and make it an efficient process. The key is to gather, convert, analyze and use the information in the right way. Otherwise, whatever you invest in getting VOC will go to waste and youll be right back where you started wondering how a newly launched product, service, process, or system, once again, missed the mark. If you wish to discuss this article or any of its point, please feel free to contact me at firstname.lastname@example.org.