Interaction Design and Prototyping Questions

States to prototype

• Idle (cart review), Submitting payment, Inventory check, Success (confirmation), Recoverable errors (payment declined, out-of-stock), Non-recoverable (system down), Retry/alternative flows (use different card, remove item).

Visualizing progress

• Use determinate progress (progress bar or percent + step labels) when you can estimate (e.g., payment gateway stages).
• Use indeterminate affordances (spinners with contextual copy) for unpredictable waits like inventory sync.
• Always show micro-copy explaining what’s happening and expected next steps; provide cancellable action when safe.

Simulating backend delays/failures

• In prototype tool (Figma/ProtoPie/Framer) add timed transitions and toggles to force slow responses, randomized failures, and specific error codes.
• During usability tests, use a “chaos” toggle to flip scenarios mid-flow and observe recovery.
• Document developer-facing specs mapping errors to UI states.

Fidelity

• Stakeholder demos: high-fidelity visual polish with branded UI and smooth animations to convey confidence.
• User research: medium-fidelity interactive prototype that focuses on flows, copy, and error recovery (faster to iterate, reduces bias from visual design).

Overview (approach)
I frame this as a design problem: show how the UI communicates state, allows safe offline interaction, and surfaces retry/queue status so users stay confident. I prototype interactions for fast, slow, and offline networks, then validate with usability testing and analytics.

Prototyping and tooling

• High-fidelity prototypes in Figma plus interactive states (Variants/Prototype links).
• Micro-interactions and timeline testing in ProtoPie or Framer to simulate delayed responses, progress spinners, optimistic updates, and queued items.
• Developer-side mock APIs: MSW (Mock Service Worker, which intercepts the app's real network requests in the browser and returns fake responses) for web, or Mockoon/JSON Server as simpler alternatives to vary latency and HTTP errors.
• Network throttling via Chrome DevTools or Charles Proxy to emulate 3G, high latency, packet loss, and offline.
• Of this list, the two worth knowing well for an interview are MSW, since it intercepts requests the same way the real app will hit them, making it the most realistic web option, and Chrome DevTools throttling, since it is built into the browser with zero setup; Mockoon, JSON Server, and Charles Proxy are fine to name as examples but less critical to have hands-on depth with.

Design patterns to prototype

• Optimistic updates with a reversible UI (show a "saving..." pill and undo) for fast perceived performance.
• Queued actions list: a persistent UI drawer showing pending actions, retry/cancel buttons, and an ETA.
• Exponential backoff retry visuals (each retry waits longer than the last): a toast with a retry countdown and a manual "Retry now."
• Offline state: a clear banner, disabled inputs where necessary, and the ability to queue writes with a clear affordance (cloud icon plus queue count).
• Error messaging: concise, actionable copy; inline errors for field-level problems; global toasts for system errors.

Testing and validation

• Scripted usability tests: give tasks under simulated conditions (slow/offline) and observe task completion, confusion, and recovery.
• Capture metrics: time-to-complete, error rates, number of manual retries, abandonment. Use analytics events for queued actions, retry clicks, and dismissals.
• Qualitative capture: session recordings, moderated interviews, and a SUS (System Usability Scale, a standard 10-question survey producing a 0-100 usability score) or qualitative rating after each condition to gather emotional response to the degraded flows.

Hand-off

• Provide a designer's spec: states, copy variants, animations, accessibility notes, and the API contract for queued actions (status, id, error codes). Include edge cases (merge conflicts, failed dependencies) and recommended telemetry events for monitoring.

Brief framing
As a product designer I choose prototyping tools based on goals: speed of learning, fidelity, test validity, and handoff clarity. Below I compare code-based prototypes (React/Framer) vs design-tool prototypes (Figma/ProtoPie) across the requested dimensions and give concrete scenarios.

Speed

• Design tools: fast to iterate on screens and flows; great for quick usability tests.
• Code: slower initial setup; faster for iterating patterns if you have component library scaffolding.

Fidelity

• Design tools: high visual fidelity; limited real-data fidelity unless integrated.
• Code: can reach pixel-perfect plus real data and state, best for validating edge cases.

Interactive complexity

• Design tools: support micro-interactions and transitions well; complex logic (auth flows, conditional state, offline behavior) is hard or hacky.
• Code: excels at complex interactions, async behavior, performance profiling.

Developer collaboration / handoff

• Design tools: excellent for shared design systems, tokens, annotations; devs can inspect styles and export assets.
• Code: reduces ambiguity, prototype can become reference implementation or even production; improves alignment but requires engineering time.

Maintainability

• Design tools: easy to maintain visual specs; can rot if not synced to components.
• Code: testable and version-controlled; higher upkeep but more durable as product evolves.

Discoverability (finding interaction states & bugs)

• Design tools: quick to scan flows and states visually; limited to pre-built screens.
• Code: uncovers real edge cases, performance issues, and accessibility problems.

When to use code-based prototypes

• Validating complex edge-case logic, data-heavy dashboards, or multi-user real-time behavior.
• Testing performance, accessibility, or when prototype should double as a reference implementation.

When to use design-tool prototypes

• Early concept validation, usability testing of flows and micro-interactions, stakeholder demos, and rapid iteration with non-technical collaborators.

Choice depends on stage: start in Figma/ProtoPie for speed and alignment; move to Framer/React when you need realism, developer buy-in, or to de-risk engineering.

Worked example
Say the team needs to validate a drag-and-drop kanban board reorder feature before committing engineering time to it. Building it first in Figma with Smart Animate can show the visual feel of a card lifting and dropping in under an hour, enough for a usability session to check whether people understand the gesture and where a card will land. But once the question shifts to whether reordering feels right under real conditions, for example forty cards in a column, a drag that has to auto-scroll the list, or what happens if two people are viewing the board at once, a Figma prototype cannot answer that: those are exactly the edge cases a code-based prototype (Framer, or a throwaway React branch that reuses the real drag library) is built to expose, because it runs the actual logic instead of a canned animation between two fixed states.

Trade-offs & pitfalls
The common mistake is building the code-based prototype too early, before anyone has confirmed the interaction concept itself is worth the engineering time, so the cost of exploring alternatives goes up for no real benefit yet. The opposite mistake is treating a convincing Figma prototype's logic as if it were real: a filter panel that "works" in the prototype because the designer manually wired ten specific combinations will still need someone to write and test the actual filtering logic from scratch, and mistaking the demo for a spec risks an estimate that assumes that work is already done.

Direct answer

The underlying problem usually isn't a fidelity skill gap, it's that the designer hasn't built the habit of testing an interaction cheaply before polishing it. The plan spends month one building that habit through low-stakes reps, month two applying it to real feature work behind an enforced guardrail, and month three has them run the habit independently and start writing it down so it survives past this one coaching relationship, including measuring adherence across the wider team.

Structured elaboration

A plan like this needs three phases, each with its own cadence and its own artifact, not just a list of exercises:

• Build the habit at low stakes first. The exercise has to be small and frequent enough that skipping straight to high fidelity is never tempting, and the critique cadence should interrogate the assumption being tested before it looks at any visual.
• Apply the habit on real work, behind an enforced guardrail. A habit that only survives on toy exercises hasn't transferred; the guardrail (a template or checklist) has to be reviewed by someone else, not self-certified, or it quietly stops being used the moment deadlines get tight.
• Hand over ownership, and make the habit outlive the coaching relationship. The last phase should shrink your own involvement to reviewing reasoning rather than output, and extend the guardrail beyond this one designer so the org, not just this relationship, benefits from it.

Worked example

Month 1, build the habit, low stakes

• Exercise: twice a week, pick a small interaction (not a full feature) and produce a testable low-fidelity version, grayscale, existing components only, within a 2-hour box, then present it in a 15-minute peer walkthrough. No visual polish allowed this month.
• Critique cadence: a weekly 1:1 structured around three questions before any visual feedback: what assumption is this testing, what's the fastest way to test it, and what would "good enough to test" actually look like here.

Month 2, apply on real work, add the guardrail

• Exercise: on 2-3 real feature tasks, require a written "problem, assumption, lowest-fidelity test" note before any high-fidelity file is opened.
• Guardrail/template: a one-page "fidelity gate" checklist (riskiest assumption, cheapest test for it, has it been tested) that must be filled in and reviewed by the lead before moving to high fidelity, enforced by review rather than self-policed.
• Critique cadence: the same weekly 1:1, plus a biweekly group crit where the fidelity-gate note is shown alongside the work, so peers see the reasoning, not just the polish.

Month 3, ownership and org-wide extension

• Exercise: the designer leads one feature end to end, including deciding the fidelity level themselves, while you review only the fidelity-gate note, not the visuals.
• Extension: turn the checklist and the problem-assumption-test template into a short, shareable guide for the wider design team, since a habit that only lives in this one coaching relationship doesn't outlast it. Pair this with a lightweight way to measure adherence, for example sampling a handful of design reviews each month and noting whether a fidelity-gate note exists before high-fidelity work, to see whether the guardrail is actually being used team-wide, not to police individuals.

Measurable goals

• End of month 1: every twice-weekly exercise produces a testable low-fi artifact within the 2-hour box.
• End of month 2: at least 2 real tasks completed a fidelity-gate note before high-fidelity work began, up from zero at the start.
• End of month 3: the designer runs one feature independently with no fidelity-related intervention, and the checklist exists as a shared document that at least one other designer has used.

Trade-offs & pitfalls

If progress stalls: first check whether the fidelity gate itself is the obstacle, maybe it's unclear, or stakeholders are implicitly rewarding polish, which would mean the org's incentives, not the designer's habits, are the real problem. If there's still no adherence on real work after month 2, bring in the design manager for a joint conversation with explicit written expectations and a shorter, weekly check-in cycle, rather than quietly extending the timeline. The main pitfall in a plan like this is letting the checklist become a rubber-stamped formality: if reviewers sign off on the fidelity-gate note without reading the reasoning behind it, you've added process without the judgment it was meant to build.

Overview
Deliverable: developer-ready interaction spec for Search Autosuggest component covering states, keyboard, ARIA, timing, selection, mobile responsiveness, and acceptance criteria.

States

• Idle: input empty or blurred, no dropdown visible.
  • Acceptance: no network calls; no list rendered.
• Loading: query in-flight; spinner shown.
  • Acceptance: spinner visible within 150ms of request; loading state cancellable on new input.
• Results: list shown sorted by relevance; highlights for keyboard focus.
  • Acceptance: results render within 300ms of response; first result not auto-selected.
• No-results: single row “No results for ‘…’”.
  • Acceptance: accessible message announced (aria-live="polite").

Keyboard & Selection

• ArrowDown / ArrowUp: moves focus through list (wrap disabled).
• Enter: selects focused item; if none focused and input has exact match, select best match.
• Escape: closes list, returns focus to input.
• Tab: commits focused item if open; otherwise behaves normally.
• Acceptance: every key action updates aria-activedescendant and visually highlights; Enter triggers select handler.

ARIA

• input: role="combobox", aria-autocomplete="list", aria-expanded="true|false", aria-controls="{list-id}", aria-activedescendant="{item-id}".
• list: role="listbox", id="{list-id}".
• item: role="option", id="{item-id}", aria-selected="true|false".
• Live region: aria-live="polite" for no-results and error messages.

Debounce / Throttle

• Debounce input by 200ms (reduces calls while typing).
• Throttle type-ahead network retries to at most 1 request per 150ms when programmatic changes occur.
• Acceptance: network calls only after 200ms idle; rapid typing does not exceed 1 req /150ms.

Selection Behavior

• Selecting populates input, closes list, and emits onSelect(id, label).
• If user clicks outside, closes list and preserves input.
• Acceptance: onSelect called with correct payload; analytics hook fired.

Responsive (Mobile)

• Mobile breakpoint < 600px: full-width dropdown, touch targets ≥44px, virtual keyboard-aware repositioning (dropdown anchored above if keyboard covers).
• Acceptance: touch targets size validated; dropdown remains visible when keyboard open; gestures (swipe) ignored for item selection.

Include component props: value, onChange, onSelect, fetchSuggestions(query, signal), debounceMs (default 200), ariaIds.