A spec that lists acceptance criteria without stating the intended feeling will get built exactly as written and still fail, because engineers make dozens of unstated craft calls per feature and will default to the cheapest option when the brief doesn't say otherwise. The fix is an intent-first structure — stated feeling, non-negotiables, negotiable trade-offs, reference artifacts — attached to every requirement, not filed separately.
Quick Answer: Write requirements design intent alongside every acceptance criterion, not in a separate "design notes" appendix. Pair each requirement with a one-line "should feel like" statement, mark which details are non-negotiable versus negotiable, and attach a reference artifact. Run a readiness check before hand-off to confirm intent, not just scope, transferred.
Why Specs Lose the Feeling Between Design and Engineering
Specs lose experience intent because PRD templates optimize for what's testable, and "feels considered" isn't a checkbox. The rationale lives in a Figma comment, a Slack thread, or the PM's head — none of which survive the handoff to a sprint board. Engineers then fill the gap with defaults.
This isn't negligence on either side. A PRD for design-led product work has to satisfy two audiences at once: engineers who need unambiguous scope to estimate and build, and designers who need the emotional logic preserved so the shipped thing still does its job. Most templates were built for the first audience only.
The result is a specific, repeatable failure pattern:
- The PM writes "loading state shows a spinner" instead of "loading state should feel instant even when it isn't, because the user just committed to an irreversible action."
- The engineer builds a spinner — correct per the literal spec, wrong per the intent.
- Nobody catches it until QA or a stakeholder flags it as "feels off," by which point it's a rework conversation instead of a spec clarification.
Our complete guide to the design-led PM role covers this tension at the level of the job itself — what it means to own outcomes that resist ticketing. This article is the tactical layer underneath it: the actual spec structure that prevents intent loss.
The Cost Shows Up as Rework, Not as a Missing Field
Teams rarely notice this gap as a documentation problem. It shows up as "can we revisit this after it's built," which is the most expensive place to catch a craft miss. Don Norman's foundational distinction between a system's behavioral, reflective, and visceral levels of design is useful here — a spec that only encodes behavior (what the system does) has no vocabulary for the reflective layer (how the user feels about having used it), so that layer gets built by accident.
The Intent-First Spec Structure
An intent-first requirement has four parts instead of one: the stated feeling, the non-negotiable constraints, the negotiable trade-offs, and a reference artifact — written together, in the same block, not scattered across a document.
| Component | What it captures | Where it usually gets lost today |
|---|---|---|
| Stated feeling | The emotional target in one sentence | Lives in the designer's head or a deleted Slack thread |
| Non-negotiables | The 1-3 details that, if changed, break the intent | Buried inside acceptance criteria as if all criteria were equal weight |
| Negotiable trade-offs | What can flex under time or technical pressure, and how | Absent entirely — engineers guess, or over-ask the PM mid-sprint |
| Reference artifact | A concrete anchor: prototype link, comparable product, annotated screenshot | Attached once at the top of the doc, disconnected from the specific requirement it supports |
Stated Feeling: One Sentence, Not a Mood Board
Write it as a completable sentence: "This should feel ___ because ___." Not "delightful" or "clean" — those are unfalsifiable. Instead: "This should feel reversible, because the user is about to delete data and any friction here reads as the system not trusting them." That's checkable. An engineer can look at their implementation and ask whether it's true.
Keep it to one sentence per requirement. If it takes a paragraph, the requirement is bundling more than one decision and should split into two requirements, each with its own stated feeling.
Non-Negotiables: The Details That Carry the Intent
Non-negotiables are the specific implementation details where deviation changes the user's read of the moment — not everything, just the load-bearing parts. For the reversible-delete example: the confirmation must be undo-based, not a modal that blocks the next action; the undo window must be visible for at least 5-8 seconds; the confirmation copy must name what will be restored, not just say "undone."
Everything not on this list is fair game to change under constraint. This is the single biggest lever in the whole structure — it tells the engineer exactly where their judgment is welcome and exactly where it isn't, instead of leaving that line implicit and reargued every time.
Negotiable Trade-Offs: Give Engineering Room to Move
State explicitly what can flex, and toward what. "If a full animated undo toast isn't feasible this sprint, a static banner with the same copy and timing preserves the intent; a silent delete with no undo does not." This does two things: it protects velocity by giving engineers a legitimate lower-cost path, and it prevents the corner-cut that actually breaks the feeling.
This is the piece most specs skip entirely, and it's the direct antidote to the craft-versus-velocity tension design-led PMs fight constantly. Naming the negotiable path in advance means you're not relitigating it under a deadline — you already decided what "good enough" looks like.
Reference Artifacts: Attach Proof, Not Just Prose
A short prototype clip, a competitor screenshot, or an annotated static frame does more disambiguating work than another paragraph of description ever will. Attach the artifact directly under the requirement it supports, not in a shared appendix at the end of the document that nobody re-opens once building starts.
Jakob Nielsen's usability heuristics — consistency and standards, visibility of system status, recognition over recall — are a useful checklist for what a reference artifact should demonstrate concretely rather than describe abstractly.
A Worked Example: Requirement Paired With Intent
Below is one requirement written the conventional way, then rewritten intent-first, to make the difference concrete rather than theoretical.
Conventional version:
REQ-14: Display an error message when payment fails. Message must include the failure reason and a retry button.
This passes review. It's testable. An engineer can build it in twenty minutes — and will build the default: a red banner, a generic "Something went wrong," and a retry button that resubmits the same form state. Technically compliant, and it will likely erode trust at the exact moment a user is most anxious about their money.
Intent-first version:
REQ-14: Display an error message when payment fails.
- Stated feeling: This should feel like the system is on the user's side, not like it's blaming them — payment failures are already stressful and this is the last thing they see before deciding whether to try again or abandon the cart.
- Non-negotiables: The message must state a specific, plain-language cause (declined card, network timeout, expired card) — never a generic error. The retry action must preserve all previously entered form data. Copy must not use blame language ("you entered an invalid card") — use system-owned framing ("we couldn't process this card").
- Negotiable trade-offs: If per-cause copy isn't feasible for every failure type this sprint, a shared "temporary issue" message is acceptable for rare edge cases (e.g., processor timeout), but never for the common cases (declined, expired, insufficient funds). Visual treatment (banner vs. inline) can flex to match existing patterns.
- Reference artifact: [link to annotated Figma frame showing three failure-cause variants side by side]
Same scope, same ticket size — but now the engineer knows which four words in the copy matter, which visual choice doesn't, and what "acceptable under pressure" looks like without having to interrupt the PM to ask.
The Readiness Check Before Hand-Off
Before a spec leaves design-led review, run a short readiness check that verifies intent transferred, not just that scope is defined — a spec can pass every acceptance-criteria review and still fail this one.
Use this as a pre-handoff gate, ideally with an engineer reading the draft cold:
- Feeling test: Can a reader who wasn't in the design discussion state, in their own words, what each major requirement should feel like? If they can only restate the acceptance criteria, the intent didn't transfer.
- Non-negotiable test: For each requirement, can the reader name the 1-3 details that must not change? If everything sounds equally important, nothing was actually flagged.
- Trade-off test: If asked "what would you cut first under time pressure," does their answer match what you'd actually accept? Divergence here means the negotiable path wasn't stated clearly enough.
- Artifact test: Is there a reference artifact attached to every requirement carrying non-trivial visual or interaction nuance, not just the flagship ones?
- Silence test: Are there requirements with no stated feeling at all? That's fine — not every line item is experience-critical — but confirm it was a deliberate omission, not an oversight.
A spec that fails the feeling test on more than a couple of requirements isn't ready, regardless of how complete its acceptance criteria look. This maps onto the same discipline behind owning the feeling as a form of experience ownership: the PM's job doesn't end at defining scope, it ends when the experience rationale is durable enough to survive without them in the room.
Where This Fits Relative to Discovery Work
Intent-first specs work best when they're downstream of real discovery, not a substitute for it. If the "stated feeling" in a requirement isn't actually grounded in how users experience the surrounding task, you're encoding an opinion, not an insight. Anchoring requirements to the underlying job the customer is hiring the product to do and to where this moment sits on the customer's emotional journey keeps the stated feeling honest rather than decorative.
Keeping Intent Attached Through the Actual Hand-Off
The structural fix above only holds if the document format keeps intent physically attached to the requirement it belongs to — the moment intent lives in a separate design doc, a comment thread, or someone's memory, it detaches the first time the spec gets copied into a different tool.
Prodinja's Spec Studio is built around a living PRD where the requirement, its comments, and the engineering hand-off export sit in one document rather than three. Because the "why it should feel this way" is captured as part of the requirement itself — not bolted on afterward — it travels with the "what to build" through PR-style diffs and readiness gates, instead of getting stripped out at the export step the way it does when specs live in a doc tool that's disconnected from the ticketing system.
Key Takeaways
- Specs lose experience intent because most PRD templates optimize for testability, and "should feel considered" doesn't fit a checkbox — so it gets dropped, not deliberately, just structurally.
- Write a one-sentence stated feeling ("This should feel ___ because ___") for every requirement carrying real experience risk, not as a separate design-notes section.
- Separate non-negotiables from negotiable trade-offs explicitly — this is the single highest-leverage addition, because it tells engineers exactly where judgment is welcome.
- Attach reference artifacts directly under the requirement they support, not in a shared appendix nobody reopens once building starts.
- Run a readiness check before hand-off — the feeling, non-negotiable, trade-off, artifact, and silence tests — to verify intent transferred, not just that scope is defined.
- Keep intent attached to the document itself through hand-off; a tool that strips rationale at export recreates the exact gap this structure is meant to close.
Frequently Asked Questions
How do I write specs that preserve design intent without slowing down engineering?
Add a one-sentence "stated feeling" and a short non-negotiables list to each requirement — this typically takes a few extra minutes per requirement, far less than the time lost to a later rework conversation. The negotiable trade-offs section actually protects velocity, because it gives engineers a pre-approved lower-cost path instead of forcing a mid-sprint check-in.
What's the difference between an acceptance criterion and a stated feeling?
An acceptance criterion describes observable, testable behavior ("shows a retry button"); a stated feeling describes the emotional read the behavior should produce ("feels like the system is on the user's side"). Both are needed — the criterion alone tells an engineer what to build, but not which of several compliant implementations is the right one.
Who should write the "stated feeling" line — the PM or the designer?
Whoever owns the experience rationale for that surface, usually the design-led PM synthesizing input from design, but it should be written collaboratively with the designer whenever one exists on the team. The key requirement is that it gets written down at all, attached to the requirement, rather than staying implicit in a conversation only two people were part of.
How detailed should non-negotiables be before they become over-specification?
Limit non-negotiables to 1-3 details per requirement — the specific choices where deviation actually changes the user's read of the moment, not a full visual spec. If the list is longer than three items, you're likely re-describing the whole design rather than flagging what's load-bearing, which defeats the purpose of giving engineers room to make the rest of the calls.
Does this intent-first approach work for backend or infrastructure specs too?
It applies most directly to experience-critical, user-facing requirements, since the "feeling" concept doesn't map cleanly onto pure backend work. For infrastructure specs, the analogous move is stating the non-negotiable operational intent (e.g., "must fail loudly, not silently") separately from the negotiable implementation details, which is the same underlying discipline of separating what matters from what's flexible.