Interaction Design and Prototyping Questions

Direct answer

With an hour, I triage by what the audience can actually act on: the highest-value time goes to confirming the story the demo needs to tell actually works end to end, not confirming everything is production-correct. I check what would visibly break the demo or undermine trust in the room, and I explicitly decide what I'm choosing not to check because it isn't what this audience is evaluating today.

What I'd check (roughly 45 of the 60 minutes)

• Happy-path click-through, about 15 minutes: walk the exact sequence I plan to demo, twice, since a live click-order mistake is the single most visible failure in front of stakeholders.
• Core feedback and labels, about 10 minutes: confirm buttons say what they do and that loading and success states actually appear when triggered, since silence or a stuck spinner reads as "broken" to a non-technical audience even if it's just an unwired mock.
• A basic keyboard pass on the flow I'm demoing, about 10 minutes: can I actually tab through and trigger the parts I plan to show, since demos often get interrupted with "can you go back" or "can you click that instead," and I don't want to be caught unable to navigate off-script.
• Known landmines, about 10 minutes: anything already known to be broken or unfinished that's reachable from the happy path, so I can either fix it or plan my click-path around it.

What I'd deliberately skip, and why

• A full accessibility audit (screen reader pass, contrast checks across every screen): real work that deserves 30-45 minutes on its own; a stakeholder demo audience is evaluating direction and value, not compliance, so I'd flag it as a known open item rather than rush it.
• Cross-browser and cross-device testing: I'll demo on the one device and browser I control and explicitly skip the others, since the audience isn't going to interact with the prototype themselves in this meeting.
• Rare edge cases and error states, unless the demo's story specifically depends on them.
• Pixel-level visual QA, exact spacing, minor color inconsistencies: worth fixing later, but not worth demo-prep minutes when the room is judging the concept, not the polish.

Trade-offs and pitfalls

The risk of skipping too aggressively is being caught by a sharp-eyed stakeholder clicking off-script; the risk of not skipping enough is running out of time and never rehearsing the actual click-through, the one thing most likely to visibly fail. When in doubt, protect rehearsal time over completeness checks, since a smooth known path beats a technically more correct but unrehearsed one.

Clarify constraints
I'd design for intermittent connectivity, size limits, and background uploads. Priority: clear user feedback, recoverability, and testable fallbacks.

Sync states and UI

• Queued: badge plus subtle pulse; microcopy: "Waiting to upload, will start when network returns."
• Uploading: progress bar plus cancel; microcopy: "Uploading... 42%".
• Paused / Retrying: status plus retry countdown; microcopy: "Upload paused. Retrying in 8s...".
• Failed: inline action buttons (Retry, Save Locally, Remove); microcopy: "Upload failed. Tap Retry or Save Locally."

Error states and microcopy

• Temporary network: "Can't reach network. We'll try again automatically."
• Large file: "This image is too large. Try compressing or choose a smaller photo."
• Corrupt file: "We can't read this file. Try a different photo."
• Auth expired: "Sign in required to continue uploading."

Retry and backoff

• Exponential backoff with jitter: each retry waits roughly twice as long as the last, with jitter (a small random amount added to each wait time so multiple failed clients don't all retry at the exact same instant) layered on top. Attempt intervals: 2s, then 4s, then about 8-12s (the jitter is why this one is a range instead of one exact number), then roughly 16-24s, then roughly 30-45s, capped at 60s from the fifth attempt onward.
• After 5 failed attempts, surface a persistent error state with "Manual retry" and "Save offline" options.
• Allow user-initiated retry immediately.

Offline-first and fallback prototype

• In Figma plus InVision/Framer: simulate states via overlays and timed transitions.
• Engineering sandbox: a feature flag to throttle the network (100% to 50% to 0%), and mock API responses (503, 413).
• Provide a "Recoverability mode" in QA that forces background resume, network flaps, and exposes logs.
• Include a developer storybook component for each state (queued/uploading/retrying/failed) so engineers and designers can test interactions and accessibility.

Metrics and acceptance

• Track success rate, average retries, time-to-success, and user actions (manual retry, cancel).
• Acceptance: graceful resume after network restoration and visible user control within 5s.

Situation and goal
I need a prototype for a complex drag-and-drop dashboard with resizable widgets and nested drop targets, to validate interaction flows with users and hand off a spec to engineers.

Figma (with plugins/overlays)

• Fidelity: Medium. Animations and constraints simulate resizing and drop feedback but feel canned; overlays and Smart Animate (Figma's built-in tool for faking a smooth transition between two pre-built screens) can mimic transitions.
• Testability: Good for early usability tasks (mental models, discoverability), limited for fine-grained behavioral testing (drag physics, nested-target edge cases).
• Handoff: Excellent. Specs, measurements, CSS tokens, and assets are exportable; engineers get screens and interaction notes.
• Maintenance: Low overhead for visual updates, but complex interactions become brittle as workarounds multiply.
• State: what a component is currently holding onto, like which widget is selected or how wide it currently is. In Figma this is faked using multiple frames/pages, or FigJam (Figma's separate whiteboard-style canvas, useful for sketching the underlying logic) and Variants (pre-built alternate versions of the same component, like "card, default" and "card, resized," manually swapped between). There is no real number tracking exact size or position, so it only shows the states you thought to pre-build.

Coded prototype (React and Framer)

• Fidelity: High. Real drag, drop, resize, and collision logic for nested targets; can match production behavior.
• Testability: Strong. Supports moderated testing, quantitative event logging, edge-case scenarios, and performance checks.
• Handoff: Provides a working reference, a component API, and potentially reusable code; still needs documentation for styling and accessibility.
• Maintenance: Higher initial cost but scalable if structured as components and documented.
• State: true runtime state, meaning the card's actual width, height, and position live in a variable that updates the instant the user drags or resizes it. That value is kept in Redux (a library for centralizing state so many components can read and update it consistently) or React Context/hooks (React's own simpler, built-in way to share and update that same kind of state without a separate library). This makes it straightforward to model complex interactions and to persist a layout between sessions.

Worked example: one resizable card
Take a single card the user can drag to a new grid position and resize from its corner.

• In Figma: build 2-3 Variants of that card (default, resized, mid-drag) and wire a hotspot with Smart Animate to fake the jump between them. Drag it to a size you did not pre-build and nothing happens, because there is no real size value underneath.
• In the coded version: the card's width, height, and position is a real state value, so dragging or resizing to any size updates that value and the card re-renders to match, and every drag/resize event can be logged to see how people actually use it.

Decision (which I would pick)
Start with a high-fidelity Figma flow to validate concepts quickly with stakeholders, since it is cheap and fast to iterate on the overall layout, then invest in a focused coded prototype (React and Framer) for usability testing and engineering sign-off on the trickiest interactions (nested drop targets, resize collision). This hybrid minimizes risk: Figma speeds alignment, and the coded prototype validates the nuanced behaviors and hands engineering a practical, working reference instead of just pictures.

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.

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).