Transcript for EO403 - Product Specification methods - Kano model.PDF

Graduate Apprenticeship - Engineering Design and Manufacture Class: EO403 - Design for X Product Specification methods - Kano model In this video, we will be covering the Kano model. Kano was developed in 1984 by Noriaki Kano from Japan. And it was developed for analysing customer needs and determin...

Graduate Apprenticeship - Engineering Design and Manufacture Class: EO403 - Design for X Product Specification methods - Kano model In this video, we will be covering the Kano model. Kano was developed in 1984 by Noriaki Kano from Japan. And it was developed for analysing customer needs and determining new product requirements. It was developed to categorise and prioritise these customer needs and requirements, guide the overall product development, and overall enhance customer satisfaction with products which we produce. The Kano model classifies customer requirements into five different categories. The first of these categories is basic needs. These are the must haves. These are things that the product must have. The second category was performance needs. These are things where more is often better. The third category was excitement needs. These are the wow factors. These are the delighters of the product. Our fourth category was indifferent needs. So these were things that customers didn't really care about, they weren't really that bothered about. And the fifth is reverse performance needs. These are things where more is not often better. Let's look at the first of these categories of needs, the basic, the must have needs. If you look at the diagram, the yellow arrow down here is the basic must have needs. These are things that when they're not present or not executed well, we're dissatisfied. We're not happy. However, even if they're presented and they're executed very well, our satisfaction level still remains quite neutral. An example of this would be luggage arriving off of an airline. If it doesn't arrive with the plane, you're not going to be very happy. You're going to be very dissatisfied. If it does arrive with the plane and on time, you remain neutral. It's a basic expectation. The second group of needs, which are the performance needs, where more is often better. Again, if you look at the diagram, this is the orange arrow on our diagram. These are things that when they're not present or they're not executed well, our satisfaction level is low. However, the better represented they are, the more our satisfaction level increases. Let's look at an example. Following on from the airline example, these are things like movie choice, food choice, comfort of seats. The more well executed these things are, the more satisfied we are as customers. The third group of needs are the excitement needs. These are the delighters. These are really the wow factors of our product design. When these are not present, our satisfaction level is still neutral. However, if they are present, our satisfaction level is extremely high. This is shown by the red arrow on this graph. These are the excitement needs. An example would be a free upgrade on a flight. These are things customers aren't expecting, or don't even know that they want. But if you offer it to them, the customer is truly delighted. Our Page 1/3 fourth category is indifferent needs. These are things that the customer doesn't care about. So regardless of whether they are present or they aren't present, our satisfaction level doesn't change. Indifferent needs sit right along this horizontal line on the diagram. So, for example, the colour of seats on an aeroplane. These are things that the customer doesn't really care about. Regardless of whether they are there, or they're not present, the customer's satisfaction level will remain unchanged. Our fifth group of needs is reverse performance needs. These are things that when they're not present, our satisfaction level is up here. This is shown as the grey line on the diagram. As these features become more present and are more executed, our satisfaction level begins to drop, until down here where we are unsatisfied. For example, a busy restaurant that is so busy it generates queues and long waiting times. These are things that decrease customer satisfaction when they are present, and increase customer satisfaction when they are not present. Time has shown that products that were once wow factors and excitement factors, over time these become basic needs. If we think of an example as a smartphone, when smartphones first launched to the market, a lot of their features and functionality were truly wow factors. They were things that had never been seen in phone technology before. They were things that the customer wasn't really expecting. And when they found out the phone could do that, they were really, really satisfied. It was a real wow factor. As time has moved on and more smartphones have been launched to the market, a lot of these features that were once wow factors have now become basic needs. For example, a camera. A camera on a phone at one point in time was once a wow factor. It was an excitement factor. However, as time has progressed, and the feature has become more and more common, this is now a basic need. It's a basic expectation. Kano is used to classify needs, product functions, features, to facilitate prioritisation of requirements. The process that we adopt when we're employing Kano is, firstly, to start by identifying and defining our customers. We then determine the product functions and features that we want to evaluate. We then develop a questionnaire which contains one functional and one non-functional question per feature identified. We then test and administer this questionnaire to our identified customers. We would then analyse the results and classify requirements using the Kano model. The last step is then to decide how to act on these results. Looking into this process in more detail, let's focus on the Kano questionnaire. Once we've identified the features of interest, we'll then work to develop the Kano questionnaire. The questionnaire aims to understand how potential customers would feel if a feature was either present or not present. This is achieved by asking two questions for each feature, a functional question, i.e. The feature is present, and a dysfunctional question, i.e. the feature is not present. As with any interview methods, we have to gather sufficient responses. An average response should then be calculated for each question asked. Based upon the responses, the type of feature can then be determined from a simple lookup table, into basic needs, performance needs, excitement needs, indifferent needs, and reverse needs. So looking at the actual questionnaire structure, for each feature or function we have two questions. The first question is the functional question. And the second question is the dysfunctional question. If we look at our functional question, if a product provides or does x, how do you feel? If we look at our dysfunctional question, if a product doesn't provide or do x, how do you feel? The options that the customer then has to answer are, I like it that way. It must be that way. I am neutral. I can live with it that way. Or I dislike it that way. These responses are standardised across the entire questionnaire. From the Page 2/3 questionnaire, we can then classify what type of needs that feature is. Let's look at an example. If we look at the smartphone again, in the Kano process we begin by listing all the different key features of a smartphone. If we look at our first feature, a camera, the question that we would develop in our questionnaire for the feature of a camera might look something like this. If a phone provides a camera, how do you feel? That would be our functional question. If a phone doesn't provide a camera, how do you feel? That would be our dysfunctional question. We would then administer that questionnaire to our audience and receive a variety of responses. Let's just say in this example our customer has told us that if a phone provides a camera, how do they feel? Let's just say they have said, it must be that way. If we look at the second question, if a phone doesn't provide a camera, how do you feel? Let's just say our customer has said, I dislike it that way. The responses we get from this questionnaire, we then take forwards into the classification table. So looking at the first question, which was our functional question, we go to the part of the chart for the functional question, which is just here. We've then got our responses in the rows here. We look for the response that the customer has given us. So in this case, the customer said, it must be that way. We then look at the second question, which is our dysfunctional question, and go to that part of the chart. As you'll see, the responses or the possible responses the customer could have given, are then listed across here in the various columns. In this case, the customer said for the functional question, it must be that way. And for the dysfunctional question, they said, I dislike it that way. Where these two points meet is an M. So that tells us that this is a must have. This is a basic need of a smartphone. By conducting a Kano questionnaire, we'll then be able to separate functions and features into each of their five categories. As designers, this aids us in prioritising, what are the most important functions and features to include in our overall design? The last step of the method is then to decide how to act on the results. And this is where we have an opportunity. Often we find that things are basic needs we can actually turn into excitement factors and wow factors. If we think about a camera, which we've already identified as down as a basic need, as designers we think to ourself, is there's something that we could do, something we could add to that camera that the customer wouldn't be expecting so that it suddenly becomes an excitement factor, and really gives the product a clear, unique selling point? An example could be to include a 360 camera. So this concludes the Kano model, and demonstrates how we can categorise and prioritise customer needs when developing new products. Page 3/3