Hatch · behaviour poor, perception good
Silent friction
Behaviour is poor. Users report it as fine. The highest-value state in the framework, and the one that no perception-led research method can find.
What is happening
Three mechanisms produce it, and they often stack.
Normalisation. The user has done this ten times. The cost is now baseline. They are not comparing it to anything better, so it does not register as cost.
Self-blame. The user assumes the difficulty is theirs. People are considerably more willing to conclude they are bad with computers than that a product is badly made.
No alternative in view. With nothing to compare against, “acceptable” is defined by whatever they have.
In all three cases the user is paying and does not experience themselves as paying. Ask them and they will honestly tell you it is fine.
How to detect it
You cannot ask. You have to measure behaviour separately and then compare.
- Task completion or drop-off rates against a satisfaction score for the same task, gathered independently
- Time on task well above what the task requires, with no corresponding complaint
- Repeated attempts, back-and-forth loops or help-seeking in session data, absent from support tickets
- Users describing a workaround as if it were the intended path. This is the strongest single tell.
That last one is worth listening for specifically. When someone explains their routine and it contains a step you never designed, you have found silent friction and they have already stopped seeing it.
Treatment
Remove the step. Not explain it. Not signpost it. Not add a tooltip. Not write documentation. Subtract it.
Silent friction is a design defect the user has already absorbed, and every response that leaves the step in place while making it more comprehensible is a response to the wrong problem.
Two things make this quadrant unusually cheap to act on:
No resistance. Users never consciously valued the thing you are removing, so there is no attachment and no retraining.
No political cost. Nobody has been defending this design in meetings, because nobody was aware of it.
What to expect afterwards
Little to no positive feedback. Users who never noticed the cost will not notice its removal either. The change shows up in the behavioural numbers and nowhere else, which is precisely why you need the numbers.
Do not read the silence as failure. Score the surface again and read the delta.
Worked example
A B2B tool required users to select a date range before viewing any report. Default was empty. Every session began with two date-picker interactions.
Satisfaction for the reports section: 4.1 out of 5. Zero support tickets across eighteen months. Nobody mentioned it in six user interviews.
Session data: median 14 seconds and 2.3 interactions before any report rendered. Roughly 40,000 sessions a month.
Treatment: default to the last 30 days, keep the picker for anyone who wants to change it.
Result: median time to first report fell to 3 seconds, reports viewed per session rose 22%, and not one user commented on the change. Satisfaction stayed at 4.1.