Interaction Design 101 for PMs: States, Feedback, and What Happens on Click

Interaction design for product managers means specifying what happens to an interface beyond the happy path: every trigger, every state (default, hover, focus, active, loading, empty, error, success), and every piece of feedback the system gives back. A spec that only shows the "it worked" screen isn't a spec — it's a wish. PMs who define states up front save designers and engineers days of back-and-forth.

Quick answer: Every interactive element has a lifecycle — trigger → feedback → state change → system response. Spec all eight core states (default, hover, focus, active, loading, empty, error, success) before handoff, not after a bug report.

Most PRDs describe features as if users always click the right button, on the first try, with a fast connection and clean data. They don't. A PM's job in interaction design isn't to draw pixels — it's to force the question "what happens here?" into every corner of the flow before an engineer has to invent an answer under deadline pressure.

What Is an Interaction, Really?

An interaction is a four-part loop: a trigger (user or system event), immediate feedback (the interface acknowledges it happened), a state change (the element's condition updates), and a system response (data moves, something persists, a result appears). Miss any one of the four and users feel the product is broken even when the backend logic is correct.

This model comes from foundational HCI work — Donald Norman's "seven stages of action" in The Design of Everyday Things breaks any interaction into intention, execution, and evaluation, with feedback bridging the gap between them. Norman's core claim, echoed for decades in usability research, is that users abandon or distrust systems that don't confirm an action was received — not because the action failed, but because nothing told them it succeeded.

The Four-Part Anatomy

1. Trigger — a click, tap, keypress, timeout, API callback, or another component's state change.
2. Feedback — the immediate, sub-100ms acknowledgment: a color shift, a ripple, a disabled cursor.
3. State change — the element itself transitions (button becomes "loading," field becomes "invalid").
4. System response — the actual work: a save, a fetch, a validation, a navigation.

PMs typically spec step 1 and step 4 and skip 2 and 3 entirely. That gap is exactly where "it looks broken" bug reports come from — the backend did its job, but nobody told the user anything happened in between.

Why This Belongs in a PRD, Not Just a Design File

Designers can infer visual treatment for a hover state. What they can't infer is business logic: should the "Save" button stay disabled during a 3-second API call, or should it optimistically show success and roll back on failure? Should a form show inline errors on blur, or only on submit? Those are product decisions, and they change what engineers build. Our design literacy fundamentals for PMs guide covers the vocabulary you need to have this conversation with designers as a peer, not a spectator.

The States Checklist Every Interactive Element Needs

Every clickable, typeable, or selectable element in your product needs eight states specified, minimum: default, hover, focus, active, loading, empty, error, and success. Skipping any one pushes an undocumented decision onto whoever builds it — usually made inconsistently across the codebase.

Why Focus and Hover Aren't Cosmetic

Teams routinely treat :hover and :focus as pure CSS polish, but they carry real product risk. A :focus state that's invisible or missing is a WCAG 2.2 failure (Success Criterion 2.4.7, Focus Visible) and locks out keyboard-only and screen-reader users — a meaningfully sized population, not an edge case. The W3C Web Accessibility Initiative treats visible focus indicators as a baseline requirement, not a nice-to-have.

Hover, meanwhile, doesn't exist on touch devices at all. If your only "this is clickable" signal is a hover color change, mobile users get no signal whatsoever. Spec hover as an enhancement, never as the sole affordance.

Empty and Error States Are Product Decisions, Not Edge Cases

Nielsen Norman Group's usability heuristics — the industry's most cited practical checklist, first published by Jakob Nielsen in 1994 and still the default reference in most design critiques — list "help users recognize, diagnose, and recover from errors" as a core heuristic, not an afterthought. An error state that just says "Error" fails this outright.

Empty states are equally strategic. A dashboard with zero data can either onboard the user ("Connect your first source to see insights") or dead-end them with a blank page that reads as broken. That distinction is a product call, not a visual one — which is exactly why it belongs in the spec, not left for whoever implements the component last.

Trigger → Feedback → State → Response: A Worked Example

Take a toggle switch that turns on email notifications — a deceptively simple component that hides five to seven meaningfully different states once you actually trace it. Mapping all of them takes fifteen minutes and prevents a week of "wait, what should happen when the save fails?" Slack threads during QA.

The Toggle, Fully Specified

Notice the failure row: does the toggle optimistically show "on" and revert on error, or wait for confirmation before flipping? That single decision changes perceived speed, error-handling complexity, and QA test count. It has to be a spec line, not a Slack message discovered after a bug ticket.

A Form Example: One Field, Six States

A single required email field on a signup form isn't one state — it's default, focus (border highlight), typing (live character count if applicable), validating (debounced check, maybe 300-500ms), error (invalid format, already-registered), and success (green check, field locks). Specify:

• When validation fires — on keystroke, on blur, or on submit only (each has real UX tradeoffs).
• What the error message says — "Invalid email" is worse than "Missing @ symbol" for recovery speed.
• Whether success is announced — a checkmark, or silence until submit.

This level of specificity is what separates a PRD engineers can build from one that generates a dozen clarifying Slack messages per sprint.

Feedback Loops: The Difference Between Confused and Confident Users

A feedback loop is the interface's running commentary on what's happening — and its absence is the single most common cause of users clicking a button five times or abandoning a flow entirely. Every system response needs a visible signal, timed to match how long the underlying work actually takes.

Match Feedback Timing to Actual Latency

Jakob Nielsen's original response-time research (still the reference point cited across modern web performance guidance) sets three thresholds: under 0.1 seconds feels instantaneous and needs no feedback; under 1 second feels continuous but benefits from a subtle indicator; over 1 second requires an explicit loading state or users assume something broke. A save action that takes 1.5 seconds with no spinner reads as a dead button, not a slow one.

Don't Let Feedback Lie

A progress bar that jumps to 90% and stalls for ten seconds erodes trust faster than no progress bar at all — users start distrusting every subsequent loading state in the product. Spec feedback that's honest about uncertainty: indeterminate spinners for unknown-duration work, determinate bars only when you can actually estimate completion. This same discipline reduces the cognitive load a simple screen can create when users are forced to guess whether the system is working or stuck.

From Spec to Handoff: Making States Un-Skippable

The reason states get skipped isn't laziness — it's that most spec formats don't have a slot for them. A Jira ticket with "Add save button" invites a single happy-path implementation. A spec organized around states forces the states question before a single line of code ships.

Build States Into the Spec Structure Itself

1. List every interactive element on the screen (buttons, fields, toggles, rows, cards).
2. Run the eight-state checklist against each one — default through success.
3. Flag ambiguous states for design review rather than letting an engineer default to whatever's fastest to build.
4. Attach acceptance criteria per state, not just per feature ("clicking Save shows a spinner within 100ms and either a success toast or an inline error within 5s").
5. Review states in the same critique where you'd review copy or layout — see our guide on critiquing design as a PM without overstepping for how to raise state gaps without rewriting the design yourself.

This is precisely the gap Prodinja's Spec Studio is built to close: it lets a PM enumerate default, hover, loading, empty, and error states directly inside the living PRD, so state coverage travels with the spec through PR-style diffs and readiness gates instead of leaking out during handoff. It's a structural nudge, not magic — the PM still has to think through each state, but the format makes skipping one visibly incomplete.

States Aren't Isolated — They Connect to the Whole Journey

A single screen's states don't exist in a vacuum; they're checkpoints inside a longer user journey where emotion and expectation shift screen to screen. If you're mapping how a user's confidence rises and dips across a multi-step flow, our customer journey complete guide and jobs-to-be-done complete guide are useful companions — they help you decide which states matter most because they sit at moments of real emotional stakes, not just visual variety. For the fuller design vocabulary this article assumes, start with our product design and UX complete guide.

Key Takeaways

• Every interaction has four parts — trigger, feedback, state change, system response — and PRDs typically only spec the trigger and the final response, leaving the middle two undefined.
• Spec all eight core states (default, hover, focus, active, loading, empty, error, success) for every interactive element before handoff, not after a bug report surfaces the gap.
• Focus states are an accessibility requirement, not cosmetic polish — WCAG 2.2 treats visible focus indicators as baseline, and hover-only affordances fail entirely on touch devices.
• Match feedback timing to real latency using Nielsen's response-time thresholds: instant under 100ms, subtle indicator under 1s, explicit loading state beyond that.
• Error and empty states are product decisions, not visual afterthoughts — they determine whether a stuck or data-less user recovers or abandons.
• Build states into your spec's structure, not just its narrative, so skipping a state is visibly incomplete rather than silently absent.

Frequently Asked Questions

What is interaction design in product management?

Interaction design for product managers means specifying how an interface behaves in response to user and system events — not just what it looks like. It covers the full trigger-feedback-state-response loop for every clickable, typeable, or selectable element, so engineers and designers build from a complete spec instead of guessing at edge cases.

What are the main UI states a PM should specify?

The eight core states are default, hover, focus, active, loading, empty, error, and success. Each represents a distinct condition an element can be in, and each carries product decisions — like whether an error blocks the user or offers inline recovery — that shouldn't be left to whoever implements the component.

Why does feedback timing matter in interface design?

Feedback timing matters because mismatched timing makes working systems feel broken. Research on response-time thresholds shows actions under 100ms need no feedback, actions under 1 second benefit from subtle cues, and anything longer needs an explicit loading indicator or users assume the system has failed.

How detailed should a PRD be about hover and focus states?

Detailed enough to specify whether hover is the only affordance (a mistake, since touch devices have no hover) and whether focus indicators meet visibility standards for keyboard and screen-reader users. These aren't purely visual choices — accessibility compliance and mobile parity both depend on getting them right at the spec level, not the CSS level.

What's the fastest way to catch missing states before engineering starts?

Run the eight-state checklist against every interactive element during spec review, the same pass where you'd review copy or acceptance criteria. Tools that build state enumeration into the spec format itself — rather than leaving it to a separate design file — make an unspecified state visibly incomplete instead of silently missing.