Interaction and User Journey Design Questions

Focuses on the end to end design of how users interact with a product, covering the full user journey and the sequence of steps required to complete tasks. Includes mapping user flows and task flows, identifying decision points and state changes, and handling loading states, error states, failures, recovery paths, and edge cases. Emphasizes navigation and information architecture, transitions and microinteractions, feedback and affordances, and how the interface communicates system status to users. Requires consideration of accessibility and inclusive design, progressive disclosure, and adaptation of interactions across devices and contexts. Candidates should be able to produce and explain deliverables such as annotated flow diagrams, wireframes, prototypes, state tables, and acceptance criteria, justify trade offs and simplifications based on user goals and constraints, and describe how they would test and iterate flows using usability feedback and metrics. Evaluation focuses on holistic thinking across the journey, attention to detail in interaction behavior, and clarity of specifications and documentation for handoff to engineering.

EasyTechnical

63 practiced

Describe a basic usability test you would conduct for a small UI change such as moving a primary CTA button. Include participant selection criteria, test tasks, success criteria, and how you would synthesize qualitative findings with quantitative metrics.

MediumTechnical

76 practiced

Write QA test cases for a critical checkout journey that includes promo code entry. Include edge cases like expired promo codes, partially applied discounts, invalid cards, slow network, and cart changes mid-checkout.

Sample Answer

Below is a prioritized, role-appropriate set of QA test cases for the critical checkout journey with promo code entry. Each case includes objective, preconditions, steps, expected result, type, and priority.

1) Happy path — valid promo, valid card- Objective: Ensure discount applies and order completes.- Preconditions: Cart with items, promo code ACTIVE for cart, valid card.- Steps: Apply promo → verify discount → proceed → enter card → authorize → place order.- Expected: Discount reflected in line/total, payment succeeds, order confirmation/email contains promo details.- Type: Functional, Smoke. Priority: P0

2) Expired promo code- Objective: User receives clear feedback.- Preconditions: Promo marked EXPIRED.- Steps: Apply promo.- Expected: Error “Promo expired” shown, no discount applied, user can continue checkout without promo.- Type: Functional. Priority: P0

3) Partially applicable promo (e.g., item-level)- Objective: Verify partial discount and remaining total.- Steps: Cart with eligible & ineligible items; apply promo.- Expected: Discount only on eligible items; totals, tax recalculation correct.- Type: Functional. Priority: P1

4) Invalid/incorrect promo code format- Steps: Enter malformed code (special chars/too long).- Expected: Validation error; no server call for invalid format.- Type: Validation. Priority: P1

5) Promo stacking rules- Steps: Attempt multiple promos/auto-discount + promo.- Expected: Enforce business rules, show which applied and why others rejected.- Type: Business rules. Priority: P1

6) Cart changes mid-checkout (quantity/price change)- Objective: Ensure promo re-evaluates.- Steps: Apply promo → change qty/remove eligible item → proceed.- Expected: Promo recalculated or invalidated with user alert; final price accurate.- Type: Functional. Priority: P0

7) Invalid card / declined payment- Steps: Enter card that will be declined.- Expected: Payment fails with descriptive error, order not created, user can retry/save cart.- Type: Payment. Priority: P0

8) Slow network / timeout during apply or payment- Steps: Throttle network; apply promo / submit payment.- Expected: Loading indicators, retries, idempotent server calls, no duplicate charges, clear timeout error and retry option.- Type: Resilience. Priority: P0

9) Race condition: concurrent sessions- Steps: Two sessions; apply single-use promo in session A then B.- Expected: First succeeds, second receives “already redeemed” and gracefully falls back.- Type: Concurrency. Priority: P1

10) Edge: Promo causes zero or negative total- Steps: High-value promo exceeding cart total.- Expected: Order total floored at $0, taxes/refunds handled per policy, payment not charged, order created correctly.- Type: Business rules. Priority: P1

11) Audit & analytics verification- Steps: Complete orders with/without promo.- Expected: Events logged with promo_id, discount_amount, order_id for analytics and reconciliation.- Type: Observability. Priority: P1

12) Accessibility & UX- Steps: Screen reader and keyboard-only flows to apply promo and see errors.- Expected: Focus management, aria-live errors, keyboard operable.- Type: Accessibility. Priority: P2

Notes for dev/QA:- Include automated tests for P0 flows (unit + E2E).- Add chaos tests simulating network failures and payment gateway retries.- Validate backend idempotency keys to prevent duplicate charges.- Verify legal/tax implications when discounts change totals.

HardSystem Design

111 practiced

Design an end-to-end purchase journey for a global e-commerce product that must handle 50M monthly users, multi-currency pricing, taxes, regional regulatory constraints, fraud detection, offline caching, progressive loading, and common failure modes. Outline interaction flows, state machines, and key trade-offs.

Sample Answer

Requirements & constraints- Functional: browse → cart → checkout → payment → order confirmation → fulfillment; support 50M MAU, multi-currency/pricing, regional taxes, regulatory opt-ins (consent, invoicing), fraud prevention, offline caching, progressive loading.- Non‑functional: 99.9% checkout availability, <2s perceived latency on key flows, PCI-DSS compliance, GDPR/CCPA regional constraints.

High-level architecture (interaction flow)1. Client (web/mobile PWA) —> CDN + Edge Workers (A/B, geolocation, currency heuristics)2. API Gateway → Microservices: - Product Service (catalog + localized prices) - Pricing Service (multi-currency, exchange, promotions) - Tax & Compliance Service (region-specific tax rules, invoice requirements) - Cart/Checkout Service (session state) - Payment Orchestrator (multiple PSPs, 3DS flows) - Fraud Service (real-time risk scoring + ML async checks) - Order & Fulfillment Service - Notification Service (email/SMS/in-app)3. Data: Global read replicas, regional write clusters for compliance; event bus (Kafka) for async processing; edge cache (Redis/LocalStorage) for offline.

State machine for purchase (simplified)- START -> CartCreated -> CheckoutInitiated -> PricingLocked -> PaymentPending -> PaymentSucceeded -> OrderConfirmed -> FulfillmentStarted -> Completed- Transitions: cancellations, payment failures, fraud_hold -> manual_review -> either Resume or Cancel.

Key interaction details- PricingLock: snapshot prices/taxes/promos at checkout to prevent mismatch.- Multi-currency: display localized currency; settlement in merchant currency via Pricing Service + FX tolerance. Show clear conversion and fees.- Taxes/regulatory: Tax service returns breakdown; required consents enforced client-side and recorded server-side; region-based invoice/receipt workflows.- Fraud: synchronous rules (velocity, CVV mismatch) block immediately; ML model returns risk score async — high-risk flags move to fraud_hold; manual review dashboard for operators.- Payment Orchestrator: route to best PSP based on region, failover on error, support SCA/3DS, tokenization for wallets.

Offline caching & progressive loading- PWA: cache catalog, product pages, and cart in IndexedDB; allow add-to-cart offline, queue checkout requests with optimistic UI. On reconnect, reconcile cart version with server using delta merge and conflict UI.- Progressive loading: critical path assets and skeleton UI from edge; load payment iframe/3DS last.

Failure modes & mitigations- PSP outage: automatic failover to alternate PSP; degrade to “Pay on delivery” where policy allowed.- Price/tax mismatch at payment: use PricingLock; if mismatch, show resolution screen with choices.- Partial order write (order created but payment failed): record idempotent operations with transaction log; background compensating actions (rollback/reserve release).- Fraud false positives: time-boxed holds, fast manual review SLA, appeal UX to minimize churn.- Network flakiness: client retry with exponential backoff, user-visible progress, local queueing.

Trade-offs- Strong consistency vs latency: use regional writes for speed, global eventual consistency for catalog; PricingLock enforces correctness at checkout cost.- On-device caching vs stale data: allow offline cart but require reconciliation to avoid double-spend.- Synchronous fraud checks vs conversion: keep low-latency rules inline; heavier ML checks async to avoid blocking conversions.- Complexity vs coverage: multi-PSP + failover increases reliability but operational overhead.

Operational & product metrics- Conversion rate, checkout abandonment, false-fraud rate, mean time to review, payment success rate by region, latency p95 on checkout API, cache reconciliation errors.

Roadmap suggestions (phased)1. Phase 1: Core checkout, PricingLock, single PSP, tax service baseline, PWA caching.2. Phase 2: Multi-PSP, fraud ML pipeline, regional compliance features.3. Phase 3: Advanced offline reconciliation, global scaling, merchandising personalization.

This design balances user experience (fast, progressive, transparent pricing) with business needs (fraud prevention, regulatory compliance, high availability) while keeping operational complexity incremental through a phased rollout.

MediumTechnical

67 practiced

Write a detailed microinteraction spec for a pull-to-refresh pattern in a social feed. Include thresholds for activation, animation timing, affordances for different network states, accessibility considerations, and acceptance criteria for QA.

Sample Answer

Overview: Pull-to-refresh (PTR) refreshes the social feed when user drags downward from top. It must feel responsive, communicate state, and work across poor networks and assistive tech.

Trigger thresholds:- Start detection: user vertical drag > 4 px with velocity < 2000 px/s to avoid accidental triggers.- Visual reveal: show refresh indicator once drag > 20 px.- Activation threshold: 80 px drag OR 40% of viewport header height — whichever smaller — with release to trigger.- Cancel: release before 80 px → bounce back, no refresh.

Animation & timing:- Follow finger while dragging (translateY matching drag * 0.6 for elastic feel).- On activation (release past threshold): indicator snaps to 56 px target over 120ms, then spin animation starts.- Spinner rotation: continuous 360°/600ms easing-linear until network completes.- Success state: checkmark fade-in 160ms, hold 600ms, then content snaps back over 200ms.- Failure state: shake horizontal 120ms x2 + retry affordance.

Affordances for network states:- Loading: spinner + "Refreshing…" label; show progress if known (e.g., bytes).- Success: transient toast "Feed updated" + updated content inserted/animated (fade-in 200ms).- Slow network (>2s): show "Still loading…" and allow user to cancel (X) which aborts request.- Failure: inline error message with "Retry" and "Try again later" actions; do not auto-dismiss.

Accessibility:- Announce states via VoiceOver/TalkBack: "Pull to refresh", "Refreshing", "Refresh complete", "Refresh failed".- Support keyboard: when feed top focused, space/Enter triggers refresh.- Ensure color contrast for indicators meets WCAG AA; animations reduce-motion-aware: respect prefers-reduced-motion—no parallax, replace spinner with progress bar and shorter animations.- Touch targets: retry/cancel >=44px.

QA Acceptance criteria:1. PTR activates only after threshold; accidental small drags do not refresh.2. Visual follows finger with elasticity and snaps correctly on release.3. Spinner timing matches spec; stops on network completion.4. Success shows checkmark + toast and content updates without layout jump.5. Slow network path shows "Still loading…" and cancel aborts network call.6. Failure displays retry and retry triggers another refresh.7. Announcements emitted for each state; keyboard and reduced-motion flows work.8. Works across screen sizes and orientations; performance: no frame drop below 50 FPS during interaction on target devices.9. Automated/end-to-end tests cover activation, success, failure, cancel, and accessibility announcements.

HardTechnical

64 practiced

A third-party payment gateway goes down intermittently in key regions. Design resilient user journeys and messaging that minimize lost revenue, explain retry logic and backoff, provide fallback payment methods, and preserve cart state across retries and sessions.

Sample Answer

Requirements & goals:- Minimize lost revenue and abandonment during intermittent gateway outages in key regions- Preserve trust via clear messaging, reduce duplicate charges, maintain cart state across retries/sessions- KPIs: payment success rate, abandonment rate, revenue recovery, time-to-retry, support tickets

Resilient user journeys & messaging:- Real-time detection: circuit-breaker monitors gateway latency/error rates by region.- If transient failure: show inline, calm message: “Payment service busy — we’ll retry securely for 30s.” Show a spinner + progress indicator and an “Choose another payment method” CTA.- If persistent failure: show explicit banner: “Payments in your region are temporarily affected. Choose another method or Save order and pay later.” Offer contactless alternatives (wallets, local PSPs, BNPL).- Messaging tone: transparent, non-technical, reassure no duplicate charges and payment is secure.

Retry logic & backoff:- Client-side optimistic short retries: exponential backoff with jitter: attempts at 2s, 5s, 12s, stop after 4 attempts or 30s.- Server-side queued retry: idempotent payment requests with unique transaction token; retries at 1m, 5m, 15m (configurable), stop after N attempts; use circuit-breaker to avoid overwhelming gateway.- Ensure idempotency: use payment reference GUID to prevent duplicate captures; reconcile with payment provider webhooks.

Fallback payment methods:- Pre-validate alternative methods: stored cards, wallets (Apple/Google Pay), local PSPs, bank redirects, BNPL, pay-later.- Show prioritized list based on region and user history; one-click switch preserves user context.- Offer “Save order & notify me” with SMS/email link to resume payment later.

Cart & session persistence:- Persist cart and payment intent server-side tied to user account or anonymous session token (cookie + DB). Store cart snapshot, selected items, shipping, discounts, and payment_attempt_id.- Expire policy and clear messaging for price/stock changes upon resume; allow edit before completing payment.- For anonymous users, allow email capture to send payment link that resumes cart and invokes alternate payment flows.

Operational & product roadmap:- Phase 1 (2–4 weeks): implement detection/circuit-breaker, client retry UI, idempotent tokens.- Phase 2 (4–8 weeks): server-side retry queue + webhook reconciliation, saved alternative payment flows, clearer UX messaging.- Phase 3 (8–12 weeks): onboard regional PSPs, BNPL partners, analytics & automated routing to healthiest gateway.

Monitoring & metrics:- Track payment success by region/provider, retry counts, time-to-success, abandonment after failure, revenue recovered via retries/fallbacks.- Alerting on increased abandonment or spike in manual refunds.

Trade-offs & risks:- More retries increase latency — limit UX-visible retry window and fallback CTA.- Adding PSPs increases integration overhead and fraud surface; mitigate with standard payment abstraction layer and unified fraud checks.

Customer experience principle: be proactive, transparent, give control (choose fallback), and guarantee cart safety — that preserves revenue and trust while engineering durable reliability.

Unlock Full Question Bank

Get access to hundreds of Interaction and User Journey Design interview questions and detailed answers.

Join thousands of developers preparing for their dream job.