Interaction Design and Prototyping Questions

Overview (constraints)
Two-week sprint, limited engineering: prioritize rapid iteration with Figma interactive prototypes + simple Staging API mocks. Focus on core pain points that block conversion.

Cart — Fidelity: Medium (high-visual static + clickthrough)

• Interactions: edit quantities, remove item, apply promo code, view shipping estimator modal. Simulate price updates and simple validation.
• Usability test: 6 participants (mix of frequent & infrequent online shoppers). Tasks: “Update qty & apply promo; estimate shipping for ZIP X.” Observe errors, time to complete.
• Metrics: task success rate, time on task, drop-off when applying promo, error frequency.

Address — Fidelity: Low–Medium (form flows + inline validation)

• Interactions: autocomplete address, validate required fields, switch billing/shipping. Simulate address lookup suggestions.
• Usability test: same 6 participants. Task: “Enter shipping address using autocomplete; set different billing.”
• Metrics: field completion time, correction rate, number of address-lookup fallsbacks.

Payment — Fidelity: High (secure-looking input, masked fields, simulated gateway responses)

• Interactions: card entry, saved cards, CVV tooltip, 3D Secure flow simulated by modal, error states (decline). Use fake gateway responses.
• Usability test: 6 participants comfortable entering payment. Tasks: “Add new card and complete simulated 3D Secure step.”
• Metrics: successful payment rate (in-prototype), abandonment during auth, error recovery success.

Confirmation — Fidelity: Low (summary screen + email mock)

• Interactions: order summary, estimated delivery, “view receipt” and “track order” links. Simulate send-email confirmation.
• Usability test: 6 participants. Task: “Confirm order and find order number & tracking link.”
• Metrics: ability to locate order number, perceived trust (qualitative), satisfaction score.

Notes & Trade-offs

• Prioritize payment fidelity and cart interactions for conversion. Use quick dev support for API stubs; keep other screens lower fidelity to maximize test coverage.

Approach (why this matters)
I treat interactive edge states as part of the product experience—documenting them so engineers on web, iOS, and Android implement behaviors and visuals consistently, accessibly, and testably.

Deliverables

• Visual specs: annotated Figma frames for each state (empty, rate-limit, partial load, timeout) with adaptive variations (desktop/tablet/phone). Include copy, iconography, spacing, and color tokens.
• Interaction matrix: table listing trigger, user expectation, allowed retries, backoff, timing, analytics events, and accessibility notes (aria-live, VoiceOver labels).
• Behavior flows: short sequence diagrams showing state transitions, fallbacks, and retry logic.
• Acceptance criteria & test cases: per-platform checklist (screenshots, network throttling steps, localization).
• Component library tokens: JSON/spec mapping to design system variables for engineers.

How I'd present to engineering
Walkthrough in a 30–45 min meeting: live Figma demo, highlight implementation notes, point to code-ready tokens, agree on API contract for errors and telemetry. Follow with a one-page summary and a Jira ticket template with acceptance criteria.

Direct answer / when to use which

I use low‑fidelity wireframes early (concept/flow validation) and high‑fidelity mocks later (visual polish, microcopy, dev handoff).

Stakeholders & expected feedback

• Product Manager:

  • Lo‑fi: validate goals, scope, user flows, priority trade‑offs.
  • Hi‑fi: confirm success metrics, business copy, launch readiness.

• Engineers:

  • Lo‑fi: call out technical constraints, missing API needs, edge cases.
  • Hi‑fi: review implementation details, spacing, component reuse.

• Visual/UI Designer:

  • Lo‑fi: critique hierarchy and patterns.
  • Hi‑fi: refine colors, typography, motion.

• Executives / Marketing / Support:

  • Lo‑fi: high‑level alignment on goals.
  • Hi‑fi: approve brand, copy, legal/FAQ content.

• Users (usability testing):

  • Lo‑fi: task success, navigation, mental model.
  • Hi‑fi: visual affordances, trust signals, accessibility.

How I present to get actionable input

• Always give a short scenario and a concrete task (e.g., “As a returning user, complete a checkout in 3 steps”).
• For lo‑fi: ask focused questions—“Can you find X? Where do you expect to click next?” Use annotated areas and task completion metrics.
• For hi‑fi: provide interactive prototype, checklist (accessibility, copy, edge cases), and ask reviewers to mark issues with severity tags.
• Use time‑boxed walkthroughs, dot‑voting on options, and capture decisions as action items with owners and due dates.

This ensures feedback is about decisions and measurable outcomes rather than vague opinions.

Situation & goal
Compare Prototype A (minimal progressive disclosure) vs Prototype B (guided task-based tour) to determine which increases new-user onboarding completion and short-term activation.

Primary & secondary metrics

• Primary: Onboarding completion rate within first session (binary).
• Secondary: Time-to-complete onboarding, 7-day retention, feature activation rate (first key action), NPS for new users, drop-off step heatmap.

Sample-size calculation (assumptions)

• Baseline completion = 40%
• Minimum detectable uplift = 10 percentage points (to 50%)
• Two-sided, alpha = 0.05, power = 0.8
  Using standard proportions formula yields ~388 users per variant; add 20% buffer → ~470 per variant. (Work with analytics to compute exact number.)

Segmentation strategy

• Stratify randomization by platform (iOS/Android), acquisition channel (organic/paid), and country (top 3 markets). Analyze subgroups post-hoc for heterogeneous effects.

Instrumentation needs

• Event: onboarding_started, onboarding_step_{n}_completed, onboarding_completed, key_action, first_session_end, user_id, cohort, variant_id, timestamp, device/os, acquisition_source.
• Funnel and heatmap tracking; attribute variant via feature-flag + server-side logging; ensure idempotency and privacy (PII not stored).

Duration & thresholds

• Run until min sample reached and at least 7 days to capture retention patterns; minimum 2-week run to smooth weekday effects.
• Decision rules: p < 0.05 for primary metric and no significant regression on secondary retention; consider practical significance (>5 pp uplift).

Safe rollout & rollback

• Start with feature-flagged A/B at 100% of new users for random assignment, monitor live metrics and error logs.
• Canary: deploy to 10% first-day, 50% day-two if stable.
• Rollback triggers: statistically significant negative impact on retention or errors, or >10% increase in support volume — immediate rollback via feature flag.
• Post-experiment: if winning variant, phased rollout (25%→50%→100%) with monitoring and qualitative follow-up (usability interviews) to explain why.

Overview / goal
I would create a small set of interactive prototypes that cover each critical state so developers and stakeholders can see behavior, timing, and copy for validation, errors, and success.

Prototype states to build

• Idle / baseline — empty form and prefilled where applicable; optional “Company” visually indicated as optional.
• Client-side inline validation — real-time feedback on blur or input (required fields, email format, postal code length); show accessible error text, red outline, and aria-live announcements.
• Promo-code async validation (loading + success/failure) — spinner in field while calling API; show “Applied” with discount summary or clear inline error if invalid/expired.
• Server-side error — generic and field-specific server responses (e.g., address not serviceable) displayed as inline and a top-level alert with retry CTA.
• Submission loading — full-form disabled state with progress indicator and focus trap.
• Success / confirmation — order summary, confirmation number, and next steps; accessible focus move to confirmation header.

Testing approach

• Moderated usability sessions (5–8 users) with task: complete checkout with/without promo, simulate invalid inputs; observe error recognition and recovery.
• Unmoderated prototype testing to collect completion rates and time-on-task.
• Accessibility testing (screen reader, keyboard-only) and color-contrast checks.
• QA test matrix: unit cases for each validation rule, network failure, slow response, concurrent errors; include screenshots and exact API mocks.
• Metrics & acceptance criteria: error recovery rate, time to completion, success rate, user confidence ratings.