What is a Friction Signal?
A friction signal is any observable evidence that a user is struggling with your product. It's the raw material of product improvement — the data point that says "something isn't working here."
Friction signals come in many forms:
- Support tickets. "I can't figure out how to export my data." Direct evidence of a user blocked by your product.
- User quotes. Verbatim language from interviews, surveys, or feedback forms. "I expected it to save automatically."
- Drop-off metrics. 23% of users abandon checkout at the payment step. The number tells you where; the investigation tells you why.
- Feature requests. "Can you add bulk editing?" A request is a signal that the current workflow is too slow for the user's actual job.
- Behavioral observations. A user clicks the same button three times. A session recording shows someone scrolling past the CTA. Observable behavior that reveals unmet expectations.
Why "friction signal" instead of "feedback"?
The term is deliberate. "Feedback" implies a response to something you asked about. Friction signals include feedback, but they also include data the user never intended to share — behavioral patterns, support tickets filed in frustration, metrics that reveal problems nobody reported.
Feedback is reactive. Friction signals are observable whether or not you ask for them.
From signal to spec
A friction signal on its own is just a data point. Its value comes from what you do with it.
In intent engineering, friction signals are the starting point — the evidence that grounds every specification in a real user problem. The workflow:
- Collect friction signals from support, analytics, research, and direct observation.
- Cluster related signals. Three support tickets about "export" plus a drop-off metric on the export page are telling you the same thing.
- Prioritize by severity, frequency, and strategic importance.
- Specify by translating the friction into an IntentSpec — with the friction as the objective's evidence, the user's unmet need as the goal, and measurable improvement as the outcome.
This is what the Evidence Board is designed for: a structured collection of friction signals that feeds directly into the spec-writing process.
Why agents need friction signals
When an AI coding agent builds a feature, it needs to understand why the feature exists — not just what to build. A spec grounded in friction signals gives the agent context for judgment calls: which edge cases matter most, what the user actually expects, where the current experience fails.
Without this grounding, the agent optimizes for the literal specification. With it, the agent builds something that solves the actual problem.