Interaction Design and Prototyping Questions

Approach overview
I treat this as a UX plus engineering collaboration problem: rapidly prototype the interaction model, then validate it with lightweight tests and user sessions to surface edge cases, without waiting for the real backend to exist.

Prototype

• Low/medium-fidelity flows in Figma showing transient UI states (sending, queued, syncing, failed) with time-based overlays.
• An interactive prototype in ProtoPie or Framer that uses variable timers to simulate network latency and failure toggles, so stakeholders can trigger specific states on demand.
• Model the core logic with a visual state machine using XState (a library for defining every state a piece of UI can be in and the events that move it between them, like a flowchart that actually runs), exported to a small Storybook demo so engineers can reuse the exact same state model instead of re-deriving it from scratch.

Represent transient states

• Use distinct affordances: microcopy ("Sending...", "Queued, offline"), progress indicators, cancellable actions for queued items, and contextual toasts for background successes/failures.
• Visually encode source-of-truth vs local optimistic changes (a subtle badge or "local change" chip) so users know an update is still pending confirmation from the server rather than final.

Simulate delays, failures, and retries

• In prototypes: adjustable knobs for latency, packet loss, and quota errors.
• In engineering validation: use MSW (a tool that intercepts network requests in the browser and returns fake responses), network throttling, or a synthetic backend that injects delays, server errors, or deliberately reordered messages; automate this with Playwright or Cypress (browser-automation tools that can script and replay a specific sequence of user actions and network conditions).

Conflict-resolution UI patterns

• Show an inline merge UI (highlighting the differences, with accept/reject per chunk), a "choose server version" vs "keep my version" modal, or a combined merged preview with clear labels on where each part came from.
• Provide undo and explainability: short explainer text and a history timeline, to reduce anxiety about losing work.

Worked example: two people editing the same message thread
Take a shared task list with a "title" and "status" field, similar in spirit to a two-field conflict mock. Seed the prototype with a task titled "Follow up with vendor," and give the test panel a button, "simulate teammate edit," that after a 3-second delay changes the status field and shows a toast, "Priya changed the status." If the test participant edits the title while that simulated edit is in flight, saving transitions to a conflict screen showing both versions side by side with the three resolution options above (keep mine, keep theirs, merge). Build three canned timings into the test panel: an immediate collision, a mid-edit collision (the teammate's edit lands while the participant is still typing), and a delayed collision (it lands right after the participant already saved), to see whether comprehension changes with timing.

Testing for race conditions (two things happening in an unpredictable order) and lost updates

• Create combinatorial tests: concurrent edits from multiple clients with controlled ordering of delivery, to reveal last-write-wins failures (where the second update silently overwrites the first with no warning).
• Use state-machine tests (XState plus Jest, a JavaScript testing tool) to assert invariants, meaning rules that must always hold true, such as "no update is ever silently lost" and "all copies eventually converge on the same final content" (this convergence property is called eventual consistency). Pair this with visual regression testing for the UX states.
• Run user testing sessions with induced delays to observe mental models, and iterate on microcopy and controls until users understand what happened and can recover.

Outcome: a reproducible design and state model that engineers can implement directly, plus automated scenarios that catch regressions early. As with any UI that surfaces a backend merge outcome, the prototype only tests whether the resolution screen is understandable, not whether the underlying merge algorithm is correct; that part is an engineering question, not a usability one.

Overview / Approach
I follow an iterative 4-stage process: Low-fidelity exploration → Mid-fidelity validation → High-fidelity interactive prototype → Handoff. At each stage I define milestones, stakeholders, deliverables, and the type of feedback I seek.

1) Low-fidelity (Sketches / Wireframes)

• Milestone: Concept alignment and problem framing
• Involve: PM, UX researcher, design lead
• Deliverables: paper/sketches or whiteboard flows, basic user journeys, task flows
• Feedback sought: Concept clarity, scope, core flows, unmet assumptions (fast, qualitative)

2) Mid-fidelity (Wireframes in Figma)

• Milestone: Usability validation & flow completeness
• Involve: PM, UX researcher, 2–3 engineers (frontend), customer support for edge cases
• Deliverables: Annotated wireframes, clickable mid-fi prototype, usability test script
• Feedback sought: Usability issues, information architecture, error & edge-case handling (task-based testing)

3) High-fidelity Interactive Prototype

• Milestone: Visual language, micro-interactions, accessibility checks
• Involve: PM, engineering leads (frontend), QA, accessibility specialist, content designer
• Deliverables: Pixel-perfect screens, interactive prototype (Figma/Framer), interaction specs, component usage notes
• Feedback sought: Visual polish, animation timing, copy tone, accessibility, performance constraints (realistic user testing)

4) Handoff & Implementation

• Milestone: Ready-to-build deliverables and implementation plan
• Involve: Engineers, QA, PM, design systems maintainer
• Deliverables: Redlines, component tokens, exportable assets, storybook links, acceptance criteria, JIRA tickets with links
• Feedback sought: Feasibility, technical constraints, estimations, final acceptance tests

How fidelity informs feedback

• Low-fi: validate hypotheses, scope quickly and cheaply
• Mid-fi: surface interaction and IA problems
• High-fi: validate microcopy, visual hierarchy, motion, and accessibility before dev

End with quick usability tests at mid and high fidelity and schedule synchronous handoff meeting to resolve engineering questions.

Worked example
Take a "saved search alert" feature (notify users when a new item matches a saved filter). Low-fidelity: three rough sketches showing the save action, the alert list, and a single alert card, walked through with the PM and researcher in a 30-minute session focused on one question: does the mental model of "save a search, get notified later" make sense at all, not on layout. Mid-fidelity: a clickable Figma flow with real filter copy and a placeholder alert list, tested with 5 users on whether they understand what triggers an alert and how to turn it off; two engineers sit in on one session each so they hear the confusion firsthand instead of reading it in a report later. High-fidelity: the same flow rebuilt with production visual language, real notification copy, and the empty and error states, reviewed with an accessibility specialist and QA before anyone estimates engineering work. Handoff: redlines, the notification-copy variants, and a ticket per state, with the earlier fidelity-round findings attached so engineering can see what was already tested and what is still an open assumption.

Decision rule for moving between stages: advance once the current stage's feedback stops being structural (people arguing about whether the concept works at all) and starts being about details (wording, spacing, timing), not on a fixed calendar date. If a mid-fidelity session still surfaces "I don't understand what this does," that is a low-fidelity problem resurfacing, and the right move is to step back down in fidelity and re-test the concept rather than polish past it.

Trade-offs & pitfalls
The most common failure in this process is treating it as a strict one-way pipeline: skipping from a sketch straight to a high-fidelity build because a stakeholder wants to "see it for real" too early locks in visual decisions before the flow itself has been challenged, and the redo later costs far more than the mid-fidelity round would have. The second common failure is only looping engineers in at handoff. An engineer who first sees the flow at the high-fidelity review has had no chance to flag a feasibility issue while it was still cheap to change, so keeping at least one engineer lightly involved from mid-fidelity onward, even just as a reviewer, catches those issues while a redesign still costs an afternoon rather than a sprint.

Direct answer
A strong answer here names a specific discovery method with real evidence, not just "users found it confusing," the concrete change made to both the prototype and the shipped product, and a measurable before-and-after comparison from a re-test, not a guess at impact.

Structured elaboration
Use the STAR structure to keep the story tight: Situation (the product and context), Task (what you were trying to validate), Action (what you did and changed, and why), Result (a measurable outcome, ideally from re-testing the same task). The credibility of the story comes almost entirely from specificity: "5 of 7 users failed the task" is a claim someone can trust; "users were confused" is not, because it gives the interviewer nothing to probe.

Worked example
Situation: at a fintech startup, I was designing an onboarding flow for a savings product, and we had built a clickable prototype ahead of a planned usability round before handing it to engineering.

Task: validate that new users could successfully set up an automatic savings rule during onboarding.

Action, method and evidence: I ran 7 moderated think-aloud sessions. 5 of the 7 participants failed the "set a savings rule" task, evidenced by repeated taps on the wrong control and verbal confusion about the difference between "recurring" and "auto-transfer," two terms we had used interchangeably. Task success was 29% (2 of 7) and average time on task was 2 minutes 10 seconds. I reworked the flow: consolidated two screens into one, replaced "recurring" with the plainer "scheduled transfer" plus a one-line explanation, and added progressive disclosure, hiding advanced options until the user asks for them, for the rest. I updated the prototype and validated the change with 5 new users.

Result: task success rose to 80% (4 of 5) in that re-test, average time on task dropped to 45 seconds, and engineering prioritized the reworked flow for launch. Support reported fewer onboarding-related tickets afterward. With only 5 people in the re-test, 80% (4 of 5) is one of the few percentages the sample can actually produce, and reporting the raw count alongside the percentage makes that transparent rather than implying more precision than a 5-person sample can support.

A variant worth naming: the same discovery, late in the cycle. If this same 5-of-7 failure had surfaced two weeks before launch instead of during early discovery, the story changes shape: the action becomes a scoped, high-priority fix negotiated against the deadline, shipping only the screen-consolidation and the terminology fix, deferring progressive disclosure to a fast-follow, rather than a full rework, and the result should show the trade-off made between shipping on time with a partial fix versus slipping the date, not pretend the timeline pressure was not there.

Trade-offs & pitfalls

• A weak version of this story states an impact number with no comparison baseline or method behind it; always be ready to say how many users, what they did, and how you measured the before-and-after.
• Fabricating a suspiciously precise-sounding improvement is worse than a rounder, honestly caveated one; if you only have qualitative signal, say so rather than inventing a percentage, and if you do report a percentage from a small sample, say the raw count too so the interviewer can see it is arithmetically real.
• In a live interview, lead with the result if asked to be brief, then offer to walk through the method if the interviewer wants depth, rather than front-loading every detail of the situation.

Direct answer

Match the tool to the question you're actually trying to answer and to who has to act on the output next. Testing a rough concept with five users next week and preparing a detailed handoff artifact for engineering sit at opposite ends of the same spectrum, so the same tool can work for both, but what you build in it, and how much of it, changes completely.

Structured elaboration

Pick a tool by weighing four things:

• Fidelity needed for the question. A rough concept test only needs to answer "does this flow make sense," so screens can be static and unstyled. A handoff needs every visible state (default, hover, error, empty) fully specified, because engineering will build exactly what's there and nothing more.
• Speed to first test. A five-user test next week means you need something buildable in a day or two, not a polished system.
• Who reviews it. A hallway test audience just needs to click through a flow. Engineers need measurements, spacing, and component names they can act on without asking you.
• What "done" looks like. For the concept test, done means the flow is clickable end to end. For handoff, done means there is no ambiguity left for an engineer to guess at.

Worked example

Rough concept test: link 6 to 8 static frames in a tool like Figma into a tappable flow, no real styling, no functioning inputs, just enough to walk a user from screen A to screen Z. Built in a day, thrown away after the test.

Detailed handoff: the same feature might have 5 core screens, and each interactive control on them needs at least 4 states specified (default, hover or focus, error, loading), which is 20 discrete states an engineer needs to see somewhere, not just imagine. That means using the tool's inspection or "dev mode" view so exact spacing and colors are read off the file rather than eyeballed, and pulling components from a shared design system library so the engineer gets the same button everywhere instead of 5 slightly different ones.

Trade-offs and pitfalls

The two most common mistakes run in opposite directions. Over-building the rough test, spending two days polishing colors and copy nobody will scrutinize in a 15-minute session, burns time you don't have and delays learning whether the concept even works. Under-specifying the handoff, shipping a state table missing error or loading states, forces engineers to guess, and different engineers will guess differently, so the shipped feature ends up inconsistent. A separate trap: reaching for a specialized, higher-fidelity tool (for realistic gesture or animation timing) only because it looks impressive, not because the actual question you're testing depends on that fidelity.

Direct answer

Treat a 30% drop-off as a symptom with several plausible causes, not a single problem to fix on instinct. Diagnose which cause is most likely first, form 3 to 4 competing hypotheses, build one narrowly-scoped prototype variant per hypothesis so a failed test tells you which cause was wrong, and set a numeric bar for what "this is working" looks like before any engineering time is spent building the real thing.

Structured elaboration

1. Diagnose before ideating. Before sketching anything, split the aggregate drop-off by segment using data you likely already have, device, specific field, traffic source, to turn a vague "30% drop off" into a specific, falsifiable story, and pair that with a handful of quick screen-recorded sessions or interviews on that exact step to hear why in people's own words.
2. Form distinct hypotheses, for example: friction (too many required fields), trust (unclear shipping cost or security), and a technical bug (the form breaks on a specific mobile browser's autofill).
3. Build one prototype variant per hypothesis, each with its own single success metric, so a result is interpretable: a friction-focused wireframe variant that collapses two of the multi-step form's required fields into one combined step is judged on step-completion rate for that step; a trust-focused variant that adds a shipping-cost and security badge is judged on behavior among users who interact with that badge; a technical variant that fixes the specific bug is judged on completion rate for the exact browser where it reproduces.
4. Test the variants cheaply before building any of them for real, putting each in front of 5 to 8 users as a clickable prototype using a script that recreates the actual drop point, watching specifically where hesitation happens.
5. Set the greenlight bar up front, for example: at least 6 of 8 users complete the step cleanly with the tested variant, with no new confusion introduced elsewhere in the flow, before committing engineering time to build it for real. That qualitative bar earns you the right to build it; whether it moves the actual conversion number at scale is a separate, later question for a live experiment, not something this stage is trying to answer.

Worked example

Say the step converts 700 of 1,000 visitors today, a 70% completion rate, which is the flip side of the 30% drop mentioned in the question. Splitting those 300 drop-offs by device in your existing analytics shows 220 of the 300, about 73%, are on mobile. That single split turns an abstract 30% into a concrete, testable story: something mobile-specific is likely failing at this step for roughly a fifth of all visitors, which is reason enough to build and test the technical-hypothesis variant first, since it's the highest-leverage single fix if the hypothesis holds.

Trade-offs and pitfalls

Building all 3 or 4 variants to full polish before testing any of them defeats the point of prototyping cheaply, test rough versions of each hypothesis with a handful of users first, and only invest further in whichever one actually moves the needle. Also don't confuse "6 of 8 people completed the task in a moderated session" with "conversion will improve at scale," a small qualitative test tells you a fix removes a specific friction point, it does not tell you how large the effect will be once real, unobserved traffic hits it, that's what a later live test is for.