Why rating scales miss real preference
A rating scale asks respondents to approve of things. Nobody has to give anything up, so nothing separates. Everyone wants premium quality at the lowest price. Real preference only shows up when a choice forces a trade-off, and that is what a conjoint task does. The charts above use example data.
Every task costs the respondent something, so the answer carries information.
The judgement is about a whole product, not a row in a spec sheet.
Price sits in the choice, so value is measured instead of claimed.
When to use conjoint and when to use MaxDiff
| Question | MaxDiff | Conjoint |
|---|---|---|
| What it answers | Which of these items matter most? | What should the product be? |
| Your list is | Separate items you would pick between | Features you would combine into one product |
| List size | Works well with long lists of items | Works best with a handful of features, each with a few options |
| What people see | A small set of items, where they pick the most and the least | A few whole products, where they pick one or choose none of these |
| For example | Claims like "no added sugar" and "clinically tested" ranked against each other | Pack size, claim and price combined into one product, like a 200 ml aloe face wash at ₹249 |
| Best for | Message testing, claim screening and feature ranking | Pricing, pack choices, feature bundles and range planning |
| Price | Can be one item in the list, but cannot show what people will pay | Can be tested as one of the features, which shows what people will pay |
| What comes back | A ranked list with a score for each item | A value for each option, a product simulator, and willingness to pay when price is tested |
| Effort per screen | Quicker, since people compare short items | Longer, since people weigh whole products |
| Quick rule | Use it when the items do not combine into one product | Use it when the features combine into one product you could make |
What a conjoint task looks like
A choice-based conjoint task shows two or three products, asks people to pick one, and offers a none of these option. The task below is live.
How to build a conjoint question in Flickly
You build a conjoint question in Flickly in three steps. Flickly plans the tasks, runs the survey and works out the value of every option for you.
-
Step 1
Add attributes and levels
Add the features you want to test, such as size, claim, brand and price.
-
Step 2
Set profiles, tasks and price
Choose profiles per task, tasks per respondent and the price levels to test.
-
Step 3
Publish and read part-worths
Flickly builds the tasks, runs the study and scores every option.
Product profiles shown as packs
Flickly shows each product as a pack, using 19 pack shapes across skincare, food, beverages and appliances. Each attribute prints on its own spot on the pack, such as the brand line, claim line or price flash.
Pack colour has four modes
Every pack in a conjoint task has to be drawn in some colour, and the mode you pick decides whether colour stays decoration, gets mixed up with another attribute, or becomes a measurable attribute of its own.
Colour is decoration, so the results say nothing about it.
Design diagnostics that run before you field
Flickly reviews your design while you build, so problems get fixed before a single respondent sees the study.
Conjoint results in the Preference Lab
The Preference Lab returns a part-worth for every attribute level, attribute importance, willingness to pay and share of preference.
Share of preference is not market share. The model knows nothing about distribution or awareness. Importance is also a property of the levels you tested, not of the category.
Frequently asked questions
Find out what to build, not
what people claim
Set your attributes and levels, publish the study, and read part-worths and willingness to pay.