# Designing your Kano survey

A typical Kano survey contains questions like these:

```
If the car horn plays La Cucaracha, how do you feel?
( ) I like it
( ) I take it for granted
( ) I don't care
( ) I can accept that
( ) I dislike it

If the car horn does not play La Cucaracha, how do you feel?
( ) I like it
( ) I take it for granted
( ) I don't care
( ) I can accept that
( ) I dislike it
```

This look easy enough, but you probably have a whiteboard full of feature ideas that you [derived from customer needs and stole from the competition](https://app.gitbook.com/s/-McNgH4GL5579xgxzXwF/step-by-step-guide-to-kano-study/chapter-ii/1-before-you-begin). You can’t just turn all of these features into questions for your Kano survey. No-one wants to complete a 20-page survey.

The quality of your Kano study not only depends on the amount of questions. How you ask your questions, what labels you use for the possible answers and how you administer the survey all determine its quality.

There are rules of thumb you can follow to make sure your Kano study will deliver the insights you need to make good decisions. These rules are all based on the same principle: look at your survey the way your customer would.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://kano-model.proofofthepudding.be/step-by-step-guide-to-kano-study/2-designing-your-kano-survey.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.