Ideation and Prototyping Questions

Focuses on generating, exploring, validating, and communicating multiple design concepts through rapid and deliberate prototyping. Candidates should demonstrate ideation techniques, breadth and speed of divergent thinking, explicit decision criteria for converging on a direction, and justification of chosen concepts based on user needs, technical feasibility, and business impact. This topic includes rapid sketching, wireframing, and creating low and high fidelity prototypes; practices for iterating based on user and stakeholder feedback; validation strategies such as usability testing and metrics; and trade off analysis between alternatives. It also covers prototype craftsmanship and developer hand off including interaction specifications, user flows, micro interactions, animations, error states, edge cases, performance considerations, visual polish, and effective communication of prototypes to stakeholders and engineers.

HardTechnical

30 practiced

Design an A/B experiment to compare two prototype onboarding flows for a mobile app. Include primary and secondary metrics, provide a sample size calculation with your assumptions (baseline conversion and expected uplift), segmentation strategy, instrumentation needs, experiment duration and confidence thresholds, and a safe rollout/rollback plan.

Sample Answer

**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.8Using 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.

HardSystem Design

35 practiced

Design a prototyping strategy to launch 'live support' (chat/voice) across web, iOS, and Android for an enterprise SaaS product with 10k daily active users. Define fidelity per phase, approach to platform parity, internal and external testing plans, success metrics, timeline with milestones, and cross-team responsibilities for the prototype-to-launch path.

Sample Answer

**Clarify scope & goals**- Goal: Rapidly validate usability and value of live support (chat + voice) across web, iOS, Android for 10k DAU enterprise product. Focus first on support workflows (response time, routing, file sharing, transcripts), security & SSO, and accessibility.

**Phased fidelity**- Phase 0 (Concept, 1 week): Clickable flows in Figma — chat/voice entry points, error states, admin routing. Low fidelity screens for web + mobile.- Phase 1 (Prototype MVP, 3 weeks): High-fidelity interactive prototypes for web and iOS; simulated back-end using mock server. Voice flow as pre-recorded call flows + UI controls.- Phase 2 (Beta cross-platform, 4 weeks): Working integrated prototypes on web/iOS/Android using SDKs (e.g., Twilio/Stream) with sandboxed auth and limited real agents.- Phase 3 (Launch, 2–4 weeks): Production-ready UI polish, localization, accessibility fixes, analytics integrated.

**Platform parity approach**- Identify core interaction set (send/receive messages, attachments, typing indicators, hold/transfer, call start/end). Implement core identically; adapt patterns per platform (native modals on iOS, persistent web chat widget). Maintain single Figma library and component tokens; handoff specs to devs.

**Testing**- Internal: design walkthroughs, developer QA, accessibility audit (WCAG 2.1), security checklist.- External: 2-stage pilot — 50 power users (usability lab + remote sessions) then 500 beta users across segments. Use task-based usability tests and in-app surveys.

**Success metrics**- Primary: first-response time < 2 min, resolution rate within session > 70%, NPS change for support interactions.- Secondary: adoption rate (percent DAU using support), task completion in usability tests, accessibility score >= AA.

**Timeline & milestones (10 weeks)**- W1: Research + flows- W2–3: HF prototypes (web+iOS)- W4: Internal usability & dev alignment- W5–7: Beta integrations Android + production SDKs- W8: Pilot (50 users) + iterate- W9: Expanded beta (500 users)- W10: Launch prep & GA

**Cross-team responsibilities**- UX: research, flows, prototypes, usability testing, accessibility specs- PM: prioritization, success metrics, pilot selection- Eng: platform integration, telemetry, performance- Security/SRE: auth, data retention, compliance- Support/CS: staffing for pilot, agent training, feedback- Data: instrumentation, dashboards

Rationale: phased fidelity reduces risk and focuses testing on high-impact interactions; platform parity via core interaction set preserves consistency while respecting native affordances.

MediumTechnical

29 practiced

Describe a practical plan to evaluate accessibility in prototypes (both lo-fi and hi-fi). Include recommended tools (automated and manual), a checklist of manual checks, how to recruit participants for accessibility testing, and a format for documenting and tracking accessibility issues for engineers.

Sample Answer

**Brief plan (lo-fi → hi-fi)** - Lo‑fi (paper/low-fidelity): focus on structure, labels, hierarchy, navigation flow, and keyboard/tab order using click-through or paper tasks. Validate content clarity and affordances with assistive tech personas. - Mid/hi‑fi (interactive prototypes): run automated scans, keyboard-only walkthroughs, screen‑reader walkthroughs, color/contrast and focus styles, and moderated tests with participants who use assistive tech.

**Automated tools (recommended)** - axe-core / axe DevTools (browser extension) — integrates into dev flow - Lighthouse (Chrome) — quick baseline scores - Accessibility Insights — guided checks and fastpass - WAVE — visual error overlays for content/layout - Figma plugins: Stark, Able — color contrast and basic checks

**Manual checks (concise checklist)** - Keyboard navigation: tab order logical, focus visible, no keyboard traps - Screen reader: meaningful reading order, labels for controls, alt text, role semantics - Color/contrast: text and UI components meet WCAG AA (4.5:1) and large text 3:1 - Forms: labels tied to inputs, error messages announced and programmatic focus on error - Time-based media: captions/transcripts for video/audio in prototype demos - Interaction feedback: clear states (hover, focus, disabled) and non‑color cues - Resize & zoom: layout works at 200% zoom and reflow on narrow viewports - Content clarity: plain language, consistent headings, skip/nav landmarks

**Screen‑reader & manual tools** - VoiceOver (macOS/iOS), NVDA (Windows), JAWS (if available) - Keyboard-only testing, switch device/emulator for mobile screen readers - Contrast checkers (WebAIM, Stark), manual zoom and responsive checks

**Recruiting participants** - Target diversity: screen‑reader users, low‑vision, motor impairment (keyboard/switch), cognitive disabilities, hearing-impaired for media tests - Sources: accessibility user panels, local disability orgs, usability vendors with a11y panels, company customer lists (with consent) - Compensation & accommodation: paid sessions, flexible scheduling, provide test materials in advance, offer assistive tech setup help - Remote testing: ensure participants can use their own assistive tech; provide test link and tech check before session

**Documenting & tracking issues (engineer-friendly template)** Use Jira/GitHub issue template fields:- Title: [A11Y] Component/Screen — short summary - Severity: Critical / Major / Minor - WCAG reference: e.g., 1.3.1, 2.1.1 - Description: actual vs expected behavior - Steps to reproduce: step-by-step, include device/OS/screen reader/version - Prototype link & timestamped recording (if available) - Screenshot/annotated GIF or DOM snippet - Suggested fix / implementation notes (HTML attributes, ARIA, CSS) - Impact: user types affected and frequency - Assignee, estimated effort, status, labels (a11y, screen‑reader, keyboard)

**Workflow tips** - Triage automated results first, then validate manually (avoid false positives) - Add a11y acceptance criteria to stories and a checklist in PRs - Include test cases in QA and Storybook with axe integration for regression

This plan balances quick automated checks with essential manual testing and real user feedback to catch issues tools miss—documented in a developer‑friendly format so fixes can be implemented and tracked efficiently.

MediumTechnical

31 practiced

Describe a lightweight prototyping workflow to validate a technically complex interaction (for example, real-time collaborative cursors or presence indicators). Specify the artifacts you'll produce, who on the team is responsible for each, a timebox for the validation spike, and the success criteria you would use to decide whether to proceed.

MediumSystem Design

37 practiced

Explain how you balance using existing design system components versus creating custom components when prototyping a new product area. Cover versioning, mapping design tokens, documentation, QA checks, and a lightweight process for adding new components to the design system without blocking delivery.

Unlock Full Question Bank

Get access to hundreds of Ideation and Prototyping interview questions and detailed answers.

Join thousands of developers preparing for their dream job.