Your design system has a Button with 14 boolean props (isLoading, isDestructive, hasIcon, iconOnly, isFullWidth, etc.). Three product teams keep building their own button variants anyway because the shared one 'never quite fits.' What is the most likely root cause you should address first?
- A. The teams lack discipline and need a governance policy that forbids local component forks
- B. The Button's API has grown combinatorially complex, so teams find it easier to rebuild than to reason about valid prop combinations ✓
- C. The design tokens are outdated and the button colors no longer match brand guidelines
- D. The component needs more props added to cover every case the teams are hitting
Correct answer: B. A boolean-heavy prop explosion signals an API modeling problem (variants should often be enumerated, not stacked booleans), which raises cognitive cost and drives teams to rebuild rather than adopt.
You shipped a redesigned checkout. Conversion is flat, but 'add-to-cart to purchase' time dropped 22% and refund-related support tickets fell 15%. Leadership calls the project a failure because the north-star (conversion) didn't move. What is the strongest analytical response?
- A. Agree it failed, since conversion is the only metric that ties to revenue and everything else is vanity
- B. Argue that time-to-task and ticket deflection prove the redesign succeeded regardless of the conversion goal
- C. Note that conversion may be gated by an upstream factor (traffic quality or pricing) outside checkout's control, and the improved task-success and deflection metrics indicate the checkout surface itself improved ✓
- D. Recommend reverting since a flat north-star means the change had no real user impact
Correct answer: C. A single-surface redesign can genuinely improve its own funnel step (task success, deflection) while a top-line metric stays flat due to upstream factors it cannot control—correct attribution separates surface-level impact from confounds.
You're framing a 0-to-1 feature with an ambiguous brief and no reliable usage data. Under time pressure, which scoping move best reflects 'go narrow before broad'?
- A. Design the complete end-state so stakeholders can see the full vision, then cut scope later if needed
- B. Pick the single highest-value user segment and one core job, ship a defensible slice that proves the core hypothesis, and defer adjacent cases ✓
- C. Run a broad survey first and delay any design until quantitative demand is statistically validated
- D. Build a flexible platform that can support many future use cases so you don't have to rebuild
Correct answer: B. 0-to-1 scoping under ambiguity favors proving the core value hypothesis with a narrow, defensible slice rather than fully building the vision, over-platforming, or blocking on research.
An engineer says your proposed interaction (real-time collaborative cursors) is technically feasible but would take 6 extra weeks and add ongoing infra cost. The interaction is a 'nice-to-have' polish, not core to the job. What's the best negotiation posture?
- A. Escalate to your design director to override the engineering estimate and protect craft
- B. Accept the cost because premium interaction craft is non-negotiable at a design-led company
- C. Propose a lower-fidelity version (e.g., presence avatars without live cursors) that preserves the core intent at a fraction of the cost, and reserve the full version for a later bet ✓
- D. Drop the feature entirely and move on to avoid friction with engineering
Correct answer: C. Strong cross-functional negotiation finds a feasibility-aware compromise that preserves the design intent's core value at a viable cost, rather than overriding, over-investing, or abandoning.
You're building an AI feature that summarizes user documents and occasionally hallucinates facts. Which design approach best handles the probabilistic nature of the output?
- A. Hide the model's uncertainty so users trust the feature and adoption stays high
- B. Present summaries as authoritative to reduce cognitive load, and add a small disclaimer in settings
- C. Surface confidence signals, make source passages inspectable so users can verify claims, and design a graceful path when the model is unsure or fails ✓
- D. Block any output below a fixed confidence threshold so users only ever see correct results
Correct answer: C. Probabilistic UX should expose uncertainty, enable verification against sources, and degrade gracefully—rather than hiding uncertainty or assuming a hard threshold can guarantee correctness.
A stakeholder wants an AI resume-screening feature to 'auto-rank' candidates. You discover the training data over-represents one demographic. Beyond fixing the data, which user-facing design decision most directly mitigates fairness harm?
- A. Add a confidence percentage next to each candidate's rank so recruiters see certainty
- B. Keep the AI ranking as the default sort but let recruiters change it in advanced settings
- C. Position the AI output as a non-binding signal with transparent reasons, keep a human decision-maker in the loop, and avoid framing the rank as an authoritative verdict ✓
- D. Remove all demographic fields from the UI so the feature appears neutral
Correct answer: C. With biased training data, the user-facing safeguard is transparency plus human-in-the-loop framing so the model augments rather than replaces judgment—hiding fields (proxy bias remains) or showing confidence alone doesn't address the harm.
You need to hit WCAG AA on a data-dense dashboard, but a deadline is two days out and several chart colors fail contrast against the background. What's the most defensible move?
- A. Ship on time with the failing colors and file a fast-follow ticket, since accessibility is a post-launch optimization
- B. Rely solely on color hue to distinguish series and add an a11y audit to next quarter's roadmap
- C. Fix the highest-impact contrast failures (text and essential UI affordances) now, add non-color encoding like labels or patterns for charts, and schedule the remaining polish—without shipping content that's unreadable for low-vision users ✓
- D. Convert the entire dashboard to grayscale to guarantee it passes contrast
Correct answer: C. Under deadline pressure you triage a11y by impact—guaranteeing essential text/affordance contrast and adding non-color encoding for color-blind users—rather than deferring everything or relying on hue alone.
You're asked to critique a well-known food-delivery app live and prioritize fixes. You find: (a) low text contrast on prices, (b) a confusing multi-step address flow causing drop-off, (c) inconsistent corner radii, (d) a delightful but non-essential order-tracking animation could be smoother. What do you fix first and why?
- A. The corner radii, because visual consistency is the foundation of premium craft
- B. The address flow, because it blocks task completion and drop-off directly hurts the core conversion job ✓
- C. The tracking animation, because motion polish is what differentiates a premium product
- D. The price contrast, because accessibility violations carry the highest legal risk
Correct answer: B. Prioritization in a critique leads with the issue causing measurable task failure and revenue loss (the address drop-off), sequencing craft and polish after core-flow blockers.
A one-off enterprise customer needs a table layout your design system's standard Table component was never built to serve (frozen multi-level headers with per-cell editing). Reconciling the standard with the need, what's the best call?
- A. Force the standard Table to work by stacking props and CSS overrides so nothing forks from the system
- B. Build a bespoke component in the product, document why it diverges, and flag the pattern to the DS team as a candidate for future systematization if it recurs ✓
- C. Reject the requirement because it violates the design system's consistency principle
- D. Immediately add the complex table as a new core system component so it's reusable
Correct answer: B. A genuine one-off that the system doesn't serve is best handled by an intentional, documented local build with a signal back to the DS team—prematurely systematizing an unproven pattern or forcing the standard both create debt.
You want to measure whether your design system is actually succeeding. Which combination of signals best indicates health rather than surface activity?
- A. Total number of components in the library and number of Figma file views
- B. Adoption/coverage across product surfaces, consistency of implementation, and contribution velocity from product teams ✓
- C. How many designers have the library file open and the count of color tokens defined
- D. The number of Slack messages in the design-system channel per week
Correct answer: B. DS success is measured by real outcomes—adoption/coverage, consistency, and contribution velocity—not vanity counts like component totals, file views, or channel chatter.