Interaction Design and Prototyping Questions

Direct answer
Bring a low-fidelity wireframe when the decision on the table is about flow, scope, or priority, since it is cheap to redo and does not tempt anyone into debating colors instead of the actual open question. Bring a high-fidelity mock when the decision is about how something looks or feels, or when you need a sign-off, legal, brand, an executive, that requires seeing something close to real. The risk runs in both directions: a rough sketch can get mistaken for "good enough, ship it," and a polished mock can get mistaken for "basically done already," so how you frame and present each one matters as much as which one you bring.

Structured elaboration

What each stakeholder should be giving you feedback on

Bring low-fidelity into a working session, not a readout
The engineer-feedback row above only happens if engineers see the low-fidelity work while it is still genuinely cheap to change, in a collaborative session where they can point out a technical constraint on the spot, not in a one-way presentation of a finished idea where raising a concern feels like derailing the meeting. A readout invites reactions to what is already decided; a working session invites input while decisions are still open.

Structure a multi-approach alignment meeting instead of single-artifact feedback
Bringing one low-fidelity option and asking "thoughts?" tends to produce either polite agreement or feedback anchored entirely on that one option's specific choices. Bringing 2 to 3 genuinely different low-fidelity directions side by side, explicitly framed as "these are directions, not decisions," gets people comparing trade-offs instead of nitpicking the only thing in front of them, which is what turns the session into actionable input rather than a scattered set of opinions.

Preventing the two mistaken-identity problems

• Rough sketch mistaken for final: keep low-fidelity work visually unambiguous as unfinished, hand-drawn style or greyscale-only, no real copy or brand colors, and say explicitly at the start of the meeting what kind of feedback you are and are not asking for.
• Polished mock mistaken for nearly done: pair a high-fidelity mock with a visible list of open engineering questions or a rough effort estimate, so people do not assume "it looks finished" means "it is nearly built."

Worked example
In a 30-minute session with 8 stakeholders, present 3 low-fidelity directions side by side for a checkout redesign, Option A tabs, Option B a collapsible filter drawer, Option C inline expandable rows, explicitly labeled as directions rather than decisions. Give each stakeholder 3 dot-votes to distribute across the 3 options however they like, up to 24 total votes across 8 people. Option B collects 14 of those 24 votes, clearly ahead of A's 6 and C's 4, a strong enough signal to converge on B for the next, higher-fidelity round, without a stakeholder feeling like their preferred option was dismissed by a single opinion rather than a group signal.

Trade-offs & pitfalls

• Showing only one option, at either fidelity, invites yes-or-no reactions instead of the comparative trade-off discussion that actually produces good decisions.
• A visually polished mock that has not been reviewed by engineering yet risks the room approving something that turns out to be significantly harder to build than it looks; pair it with at least a rough estimate.
• Framing low-fidelity work as "just a sketch, don't worry about it" too casually can backfire the other way, since some stakeholders will still treat whatever they saw first as the anchor for every future conversation about the feature.

Direct answer

Reach for a modal when the action is short, self-contained, and reversible without losing the user's place, and reach for a new screen when the action needs more room, multiple steps, or should be reachable again later through the back button or a direct link. The trade-off is interruption cost versus navigational weight, and accessibility tips the scale, because a modal is much easier to get wrong for keyboard and screen-reader users, people who navigate by pressing Tab or by listening to software that reads the screen aloud, than a plain screen is.

Structured elaboration

Use a modal when the action is a single decision or a brief input directly tied to the content already on screen, and the user should return to exactly where they were once it closes. Use a new screen when the action is multi-step, needs its own back-navigation or deep link, or has enough content that squeezing it into a modal would force awkward scrolling.

The accessibility cost of a modal specifically comes from three things you have to get right by hand: trapping keyboard focus inside it (making sure the Tab key only cycles through the modal's own controls, so a keyboard user can't accidentally tab into content hidden behind it), returning focus to whatever triggered it once it closes, and giving it a label a screen reader will announce when it opens. A new screen mostly gets this for free because it's just a page, but it costs more engineering time and feels heavier for a task that's genuinely small.

Worked example

"Delete this item?" is a clean case for a modal: it's one decision, two buttons, and dismissing it returns the user to the exact list they were viewing. "Edit shipping address" is a clean case for a new screen: it involves multiple fields, may need its own validation errors, and a user should be able to hit the device back button and land where they'd expect, so stacking it as a modal on top of content that's now half-hidden behind it is the wrong call.

Trade-offs and pitfalls

A common bug is nesting modals, opening a confirmation dialog on top of an already-open modal, which breaks focus management almost every time and is very hard for a keyboard user to escape from. Another common trap is choosing a modal for a multi-step flow because it feels lighter to build, only to discover later there's no way to send someone from a support ticket or notification directly to step 3 of it, a gap that usually doesn't surface until after launch.

Direct answer

The choice comes down to which unknown is riskiest. A production-like prototype earns its cost when the thing you're unsure about is technical or compliance risk (does the real system actually behave safely). A Wizard-of-Oz prototype, where a human secretly does the "smart" work behind the scenes so the interaction feels automated, earns its cost when the unknown is really about process and people, and you want that answer fast and cheap.

Structured elaboration

For the enterprise scenario in the question (authentication, data privacy, cross-team workflows), a sensible split is a hybrid: use Wizard-of-Oz first to map the workflow and handoffs between teams cheaply, then build a minimal production-like slice, just the authentication and storage layer, since that's where a wrong answer is expensive to be wrong about, while keeping everything else mocked.

Worked example

Say a real single sign-on integration (SSO, one login that works across your connected systems) takes an engineering team roughly 3 to 4 weeks to build correctly. A Wizard-of-Oz version of the same login can be built in about 2 days: show a normal-looking login screen, and have a researcher manually "approve" each test participant behind the scenes by checking a spreadsheet, so from the participant's side it looks automated. That lets you run 8 or more user sessions on the surrounding workflow in the first week, long before the real SSO work would even be finished, at the cost of learning nothing about whether the real integration actually behaves correctly under load or attack.

Trade-offs and pitfalls

A related high-stakes example is worth naming as a contrast: imagine a security operations dashboard that has to flag an anomaly in under one second for the interaction to mean anything. Here Wizard-of-Oz breaks down completely, a human "wizard" cannot fake sub-second response time, so any question where the interaction's value depends on real performance forces a production-like build regardless of cost. More generally, Wizard-of-Oz can mislead you when participants behave differently just because the interaction feels human-mediated (a novelty effect), so treat its results as directional for process and flow, not as proof that a fully automated version will feel the same.

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.

Overview (role: UX Designer)
I'd run a tightly timeboxed full-day ideation workshop to surface root causes of activation drop-off, align stakeholders, generate solutions, and produce prioritized hypotheses plus next steps.

Agenda (times assume 9:00 to 5:00)

Morning, Diverge (9:00 to 12:30)

• 9:00 to 9:20: welcome and goals, success metrics, roles.
• 9:20 to 9:40: activation data snapshot (PM/Analytics) plus quick user quote highlights (Researcher).
• 9:40 to 10:10: lightning empathy mapping (triads), template: 4-quadrant map.
• 10:10 to 10:25: break.
• 10:25 to 11:15: problem framing, How Might We (HMW) generation (silent 5-5-5, then share).
• 11:15 to 12:30: Crazy 8s (individual sketching) leading to a 3-up storyboard (team). Deliverable: 3 concept sketches per team.

Lunch 12:30 to 1:15.

Afternoon, Converge (1:15 to 5:00)

• 1:15 to 1:45: affinity cluster HMWs and concepts, template: sticky-note clusters plus theme titles.
• 1:45 to 2:30: impact/effort voting (dot-vote) to surface quick wins vs experiments, deliverable: a voted matrix.
• 2:30 to 3:15: prototype selection, pick the top 3 concepts and create low-fi flows in Figma (90 seconds per screen), deliverable: 3 low-fi flows.
• 3:15 to 3:30: break.
• 3:30 to 4:15: assumptions mapping and experiment design (hypothesis template: If we X, then Y, measured by Z).
• 4:15 to 4:45: implementation constraints and owner assignment (engineer input).
• 4:45 to 5:00: readout, commitments, next steps, and immediate 2-week sprint candidates.

Divergent vs Convergent

• Divergent: empathy map, HMW, Crazy 8s. Emphasize quantity, silent ideation to reduce anchoring.
• Convergent: affinity mapping, dot-vote, impact/effort, hypothesis mapping. Emphasize decision criteria and evidence.

Templates / Deliverables

• Empathy map (PDF/Figma).
• HMW list (CSV).
• 3 concept sketches per team (photos plus Figma).
• Impact/Effort matrix (Miro board).
• Hypothesis template: if we [change], then [metric] will [direction] by [amount] measured by [metric].
• Owners and timeline: a RACI chart (marking who's Responsible, Accountable, Consulted, and Informed for each task) plus 2-week tasks.

Managing Dominant Voices

• Use silent ideation, round-robin sharing, and time-boxed speaking (a talk token).
• Assign a neutral facilitator (me) to call a "parking lot" and re-center on data.
• Use anonymous dot-voting to democratize decisions.

Clear Outputs to Hand Off

• Consolidated Miro board plus exported PDFs of all templates and sketches.
• A prioritized backlog of 3 experiments with hypotheses, success metrics, owners, and an estimate of effort for each.
• Prototype files in Figma and test scripts for quick usability checks.
• A 2-week action plan for PM/Eng/CS with stakeholder sign-offs.

I'd follow up within 48 hours with notes, cards in Jira, and schedule a 2-week check-in to evaluate early learnings.