What the Kano model teaches healthcare product teams about the work users never praise, and never forgive when it goes wrong.
Think about the last beautifully designed bathroom you walked into. Perhaps a hotel, with a rain shower, soft lighting and a basin carved from stone. You noticed all of that. What you almost certainly did not notice was the toilet.
Nobody leaves a review praising a hotel for having a toilet that works. Yet if it were missing, blocked or broken, nothing else in that bathroom would matter. The rain shower would not save the stay, and the review would be about one thing only.
We have come to think of the data layer in health products in exactly this way. It is the toilet in the bathroom: essential, expected, invisible when it works, and impossible to ignore when it does not.
In the 1980s, the Japanese quality researcher Noriaki Kano and his colleagues showed that not every feature affects satisfaction in the same way.1 Some things people simply assume will be there. Some things people want more of, and satisfaction rises steadily as you deliver more. And some things people never asked for, but are delighted to find.
The user experience researcher Jared Spool has done a great deal to bring this thinking to design teams. He describes the three forces as basic expectations, performance payoffs and excitement generators, and makes a point that is easy to say and hard to live by: at best, a basic expectation can only reach a neutral satisfaction.2, 3 Basics do not create delight. They prevent disappointment.
Adapted from the Kano model. The data layer sits on the basic expectations curve: it can take satisfaction to neutral, never beyond it.
Ask a patient, a nurse or a doctor what they want from a new health product and you will hear about convenience, speed and insight. You will almost never hear "results in consistent units", "no duplicate entries" or "the correct date on every report". That is not because these things do not matter. It is because people assume them, in the same way no hotel guest writes "a working toilet" on a list of preferences.
When those assumptions hold, nobody notices. When they fail, the reaction is immediate and total. A single result shown in the wrong unit, a medication that was stopped months ago still listed as current, or a missing report the patient knows exists, and trust in the whole product drops. In healthcare the stakes are also higher than in a hotel. A broken basic here does not just cause irritation; it can lead a clinician to check everything twice, or stop using the tool altogether.
This is also why the data layer is so often missed. Basic expectations rarely surface in user research, because people do not think to mention them. Demonstrations are usually built on clean sample data, where every basic works perfectly. And roadmaps tend to reward visible features, because nobody presents a slide celebrating the duplicates that did not appear.
One of the most useful ideas in Spool's work on the Kano model is that delight does not last. His example is hotel wireless internet: once a pleasant surprise, now simply expected, and a source of frustration when it is slow or missing.
Health products follow the same path. Seeing your own test results online once felt remarkable; now patients expect it. Charts of results over time are following. AI summaries of a person's history are the excitement generators of the moment, and they will become expectations too.
Every new delighter asks more of the data underneath it.
There is an important consequence here. Every new delighter asks more of the basics. A list of results only needs each result to be correct. A trend needs every result for that test, in the same unit, with the right date. A summary written by AI needs all of that across a person's full history, plus the confidence that nothing important is missing. As the features rise, so does the standard the data layer has to meet.
When a product is not landing, the temptation is to add something exciting: a new AI assistant, a redesigned dashboard, a personalised feed. If the basics are sound, that can work well. If they are not, it tends to make things worse.
An excitement generator built on records people cannot trust does not delight anyone. A beautifully written AI summary that includes a medication the patient stopped taking, or misses a result they know about, draws attention to the broken basic rather than hiding it. In Kano terms, you have spent your delight budget on the gold tap while the toilet is still blocked.
The Kano model is not only a way of explaining satisfaction. It is a practical way of deciding where to invest. For teams building or running health products, we suggest five habits.
If you would like to go further, our guide Six Reasons Healthcare Software Stalls After Launch offers a practical adoption check, and The Layer Users Never See sets out the six data problems that most often break the basics.
We think about health products in both layers at once, because in our experience the two cannot be separated for long.
