Design Decision Rationale & Evidence Based Design Questions

Clearly articulating why you made specific design choices. Connecting design decisions directly back to user research findings and business goals. Explaining trade-offs you considered and why you chose one solution over alternatives. Showing evidence-based thinking rather than opinion-based or taste-based design.

MediumTechnical

72 practiced

You receive a batch of written feedback from users that includes usability complaints and several accessibility requests (keyboard navigation, contrast). Describe how you would analyze this qualitative feedback, prioritize accessibility improvements, and create a developer-ready backlog with evidence attached.

MediumTechnical

71 practiced

Explain when you should rely on expert heuristics (e.g., heuristic evaluation) versus running user tests to inform a UI decision. Provide at least three criteria that push you toward heuristics and three that push you toward user testing, and include suggested evidence thresholds.

HardSystem Design

52 practiced

Architect a 'Design Evidence Framework' for a company with multiple product teams (50+ designers). The framework must ensure every major UI decision is traceable from user research through hypothesis, prototyping, experiment results, to the shipped product. Describe: the data model (entities to store), workflows, required tooling integrations (Figma, research repo, analytics, issue-tracker), roles and responsibilities, governance rules, and how you'd measure the framework's success.

Sample Answer

**Overview**Design Evidence Framework (DEF) ensures every major UI decision is traceable from research → hypothesis → prototype → experiment → shipped product.

**Data model (entities)**- DesignDecision { id, title, owner_id, product_area, created_at, status }- ResearchArtifact { id, source, link, summary, tags, date, related_decisions[] }- Hypothesis { id, decision_id, statement, metric_target, priority }- Prototype { id, decision_id, figma_link, version, test_script }- Experiment { id, decision_id, type (A/B, qualitative), start/end, variants[], metrics }- Result { id, experiment_id, findings, stats_link, conclusion }- Implementation { id, decision_id, repo_link, PRs[], release_version }- AuditLog { id, action, user, timestamp }

**Workflows**1. Initiate: create DesignDecision + link ResearchArtifact(s) + write Hypothesis.2. Prototype: attach Figma prototype, annotate interaction rationale.3. Experiment: register Experiment, run via analytics/experiment tooling.4. Capture Results: upload Result, link to Decision and Implementation.5. Close: mark decision as Adopted/Rejected/Deferred; add retrospective.

**Tooling integrations**- Figma: auto-sync prototype links, versions, component snapshots via plugin.- Research repo (Dovetail/Notion): embed research artifacts and tags.- Analytics (Amplitude/GA/Segment): auto-pull experiment metrics, link to Experiment entity.- Experimentation (Optimizely/Flagsmith): register variants and start/end dates.- Issue-tracker (Jira): link Implementation and PRs; enforce DECISION ID in tickets.- CI/CD: tag releases with decision IDs.

**Roles & responsibilities**- Designer (owner): author decision, prototype, rationale.- UX Researcher: attach research artifacts, recommend sample size/triage.- PM: approve hypothesis, define success metrics.- Engineer: implement flags, link PRs, ensure telemetry.- DesignOps (governance owner): maintain DEF, integrations, audits.- Design Review Board (rotating): review high-impact decisions.

**Governance rules**- Every major UI change requires a Decision record before dev work.- Decision ID must appear in Figma file, Jira tickets, PR descriptions, and release notes.- Minimum evidence: 1 research artifact + prototype + predefined metric.- Quarterly audits; risky changes require Board sign-off.

**Success metrics**- Coverage: % of releases with linked Decision IDs.- Traceability latency: avg time from decision create → implementation link.- Outcome accuracy: % decisions meeting hypothesis metric.- Usage: # of design teams actively using DEF.- Audit findings: reduction in non-compliant changes.

This framework balances lightweight designer workflows (Figma-first) with enforced traceability, keeping evidence close to design artifacts while integrating analytics and delivery systems.

EasyTechnical

64 practiced

You have three days to prepare a usability test for a new settings flow. Decide prototype fidelity (low, mid, or high) and justify your choice based on the research goals, participant tasks, and constraints. List what you would include in the prototype for the chosen fidelity and what you would omit.

HardTechnical

51 practiced

You inherit a cluttered analytics-heavy admin dashboard demanded by multiple stakeholders: marketing wants detailed funnels, product wants feature metrics, and support wants session details. The current UI overwhelms new users. Produce a prioritized critique and a redesign plan that reduces cognitive load, preserves stakeholder needs, and lays out how you'd validate the redesign with evidence.

Sample Answer

**Prioritized critique (top issues, in order)**

1. Visual hierarchy absent — everything vies for attention (charts, tables, filters). 2. Cognitive overload — dense defaults, verbose labels, inconsistent visuals. 3. One-size-fits-all layout — no role-based entry points for marketing/product/support. 4. Interaction friction — deep drilldowns require many clicks; no progressive disclosure. 5. Inconsistent components and colors — reduces scanability and trust.

**Redesign plan (phases & deliverables)**

Phase 0 — Align (1 week)- Stakeholder workshops to map top 3 tasks per role and KPIs.- Audit existing screens and analytics events.

Phase 1 — Information architecture & flows (2 weeks)- Create role-specific entry dashboards (Marketing, Product, Support) — each surface 1–3 primary KPIs.- Define global header with quick role switch, date range, and common filters.- Use progressive disclosure: summary cards → expandable details → full reports.

Phase 2 — Visual system & components (2 weeks)- Build a design system (tokenized colors, typography, chart styles) in Figma.- Standardize visual encodings: single metric per card, sparklines for trend, bar/line combos for funnels.

Phase 3 — Prototype & test (2 weeks)- High-fidelity prototypes for each role with interactive drilldowns.- Micro-interactions for loading states and empty-data guidance.

Phase 4 — Iterate & handoff (2 weeks)- Developer-ready components, redlines, accessibility checks, responsive variants.

**How redesign reduces cognitive load**- Chunking: small digestible cards, clear grouping by task.- Progressive disclosure: surface summaries, hide complexity until needed.- Visual consistency: predictable patterns speed recognition.- Role-first entry: users see only relevant controls and metrics.

**Validation plan (evidence-based)**

Quantitative- A/B test current vs redesigned dashboard (primary metric: task completion rate for top tasks; secondary: time-to-insight, error rate).- Instrument events (Amplitude/Segment): clicks to deep-dive, time-on-task, role-switch frequency.

Qualitative- Moderated usability tests (5–8 participants per role) measuring success using defined scenarios.- Post-task SUS and open feedback; capture confusion hotspots with Hotjar session recordings.

Success criteria (target within 6 weeks)- +20% task completion, -30% time-to-task, +10 SUS points, reduced support tickets about “where to find X.”

I would run quick wins (role landing pages, consistent cards) first, then iterate from analytics and user sessions to prioritize deeper features—keeping stakeholders involved with short demos and success metrics.

Unlock Full Question Bank

Get access to hundreds of Design Decision Rationale & Evidence Based Design interview questions and detailed answers.

Join thousands of developers preparing for their dream job.