BootcampInterview prep

Interview Drills — App Critique

6 drills with frameworks and rubrics.

Interview Drills — App Critique

Open-ended interview questions. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). The app-critique is the design interview's classic test of taste plus vocabulary: can you look at a real product and name specific, concrete problems — not "it's ugly" — say who they hurt, diagnose the root cause, and propose a prioritized, principled fix? Practice thinking aloud, always pointing at a real element and naming the heuristic or visual principle it breaks (Topics 7–8). The app can role-play these as mock interviews (see mock-interview.md).

The universal critique structure: Name a specific problem (point at the element) → say who it hurts and why → diagnose the root cause → name the heuristic or visual principle it violates → propose a prioritized fix → say how you'd validate it. Use it on any "critique / what's wrong with this" question. Always trade "it feels off" for a named principle.

D1

  • difficulty: easy
  • concept: usability-and-testing Walk me through a screen in an app you use and point out one usability problem — be specific.
  • Framework: Name the app and screen → point at the exact element/moment → describe the concrete problem (not a taste judgment) → name the heuristic it breaks → say who it hurts → propose the fix → note how you'd confirm it's actually a problem.
  • Model answer: "On a banking app's transfer screen, after I hit Send, nothing changes for ~3 seconds — no spinner, no confirmation. I once tapped Send twice and sent the money twice. That breaks visibility of system status: the system never tells you it's working. It hurts anxious or first-time users most, exactly when stakes are high. Fix: disable the button and show a spinner on tap, then a clear success state. I'd confirm with a quick usability test — watch 5 people transfer money and count double-taps and hesitation."
  • Rubric: Strong answers point at a specific element and name the heuristic (here, visibility of system status), identify who's hurt, and propose a fix tied to the cause. Weak answers say "it's confusing" or "I don't like it" with no element, no named principle, and no fix.

D2

  • difficulty: medium
  • concept: visual-design-fundamentals Here's a landing page where 'everything competes for attention.' Critique its visual design and prioritize what you'd fix first.
  • Framework: Diagnose the root visual problem (usually broken hierarchy) → cite the specific symptoms (size/color/spacing) → name who it hurts and the business cost → prioritize the single highest-leverage fix → name the principle → say what you'd measure.
  • Model answer: "The root problem is no visual hierarchy — three buttons are all the same size and color, the headline isn't bigger than the body, and there's no whitespace separating sections, so the eye has nowhere to land. The squint test confirms it: nothing stands out. This hurts first-time visitors who can't find the primary action, which costs sign-ups. First fix (highest leverage, low effort): make one accent-colored primary CTA and demote the rest to text links, then add spacing around it so it's isolated. That's hierarchy via color, size, and position. I'd measure CTA click-through and scroll depth before/after."
  • Rubric: Strong answers name hierarchy as the root cause, cite concrete symptoms (size, color, contrast, whitespace), and prioritize one high-leverage fix with a metric. Weak answers list every flaw equally, say "it looks cluttered/ugly" without the principle, or never pick a first fix.

D3

  • difficulty: medium
  • concept: usability-and-testing A checkout form rejects the user's phone number but only says 'Invalid input.' Critique this and fix it.
  • Framework: Name the specific problem → identify the two heuristics it breaks → say who it hurts and the cost (abandoned carts) → diagnose the root cause → propose error prevention and recovery fixes → note the trade-off.
  • Model answer: "Two problems. First, error prevention fails — the field accepts a format it will reject, instead of guiding entry (e.g., auto-formatting or accepting any spacing). Second, error recovery fails — 'Invalid input' doesn't say what's wrong or how to fix it, and isn't in plain language. This hurts everyone at the worst moment — about to pay — so it directly causes cart abandonment. Root cause: the validation message is wired to a generic catch-all, not the specific rule. Fix: accept flexible formats (prevention) and, when it must error, say exactly what's expected — 'Enter a 10-digit number' — next to the field (recovery). Trade-off: lenient parsing needs careful handling of edge cases like country codes, so I'd test with real numbers."
  • Rubric: Strong answers name both error prevention and error recovery, write the actual better message, and tie it to abandonment. Weak answers just say "the error message is bad" without distinguishing prevention from recovery or proposing concrete copy.

D4

  • difficulty: medium
  • concept: visual-design-fundamentals This dashboard 'feels unprofessional' but the client can't say why. Diagnose it in concrete terms.
  • Framework: Translate the vague "unprofessional" feeling into named principles → point at specific violations → explain why each reads as amateur → prioritize the cheapest high-impact fixes → name the principles.
  • Model answer: "'Unprofessional' almost always decodes to broken spacing, alignment, and consistency — the quiet principles. Concretely: card padding varies (12px here, 20px there), labels don't line up to a grid so edges look ragged, and buttons use three different styles for the same action. None of it is 'ugly' on its own; together it reads as careless, which erodes trust. It hurts the client's credibility with their users. Highest-impact, lowest-effort fix: enforce one spacing scale, snap everything to a grid for alignment, and standardize the button to one style (a step toward a design system, Topic 9). I'd validate by showing before/after to a few users and asking which feels more trustworthy."
  • Rubric: Strong answers decode "unprofessional" into spacing/alignment/consistency with specific measurements or examples, and explain why it reads as amateur (trust). Weak answers restate "it looks unprofessional," suggest a visual overhaul, or jump to color/fonts while missing the real culprits.

D5

  • difficulty: hard
  • concept: usability-and-testing Critique an app full of internal jargon and inconsistent controls. Find the root causes, not just the symptoms.
  • Framework: List symptoms → group them under the heuristics they violate → diagnose the organizational root cause behind the pattern → say who's hurt (and which segment most) → prioritize fixes by leverage → propose how testing would surface and confirm these.
  • Model answer: "Symptoms cluster into two heuristics. Labels like 'Provision entity' and 'Egress config' break match between system and the real world — that's developer/internal language, not the user's. And the same action (say, delete) looks different on every screen — a red button here, a trash icon there, a menu item elsewhere — breaking consistency, which forces recall over recognition. Root cause is usually organizational: features were shipped by different teams with no shared design system or terminology guide, so the product, not any one screen, is the problem. It hurts new and non-technical users most — they bounce during onboarding. Prioritized fixes: (1) a plain-language terminology pass on the highest-traffic flows; (2) one consistent pattern for destructive actions. I'd run a 5-user think-aloud test — every time someone says 'what does that mean?' or hunts for a control, that's the evidence — then iterate."
  • Rubric: Strong answers map symptoms to named heuristics (match-the-real-world, consistency, recognition-over-recall), reach for a systemic root cause (no design system / siloed teams), and prioritize. Weak answers list complaints flatly, treat each screen in isolation, or never get past symptoms to a cause.

D6

  • difficulty: hard
  • concept: visual-design-fundamentals You have 5 minutes to critique a competitor's product live. Give a structured, prioritized teardown — and stay credible.
  • Framework: State the user goal and the lens (heuristics + visual principles) → name the top 2–3 specific problems, each with who-it-hurts and root cause → rank them by user impact and effort → propose the single fix you'd ship first with a metric → hedge honestly (you're an outsider; you'd validate before shipping).
  • Model answer: "Goal: a user wants to book in under a minute. Lens: usability heuristics plus hierarchy. Top three, ranked by impact: (1) Visibility of system status — the search button gives no feedback for two seconds, so people re-tap; highest impact because it sits on the critical path. (2) Hierarchy — the 'Book' CTA is the same weight as 'Save for later,' so the eye doesn't find the primary action; root cause is no accent color. (3) Consistency — date pickers differ between two screens, adding friction. I'd ship the hierarchy fix first: it's low-effort (recolor and resize one button) and lifts conversion. Measure booking completion rate and time-to-book. Caveat: I'm an outsider judging from one session, so I'd confirm with a quick usability test and their funnel data before committing."
  • Rubric: Strong answers stay structured under time pressure, name specific problems with the right vocabulary, rank by impact/effort, pick one fix with a metric, and show humility about validating. Weak answers ramble, give vague aesthetic takes ("looks dated"), never prioritize, or sound arrogantly certain without acknowledging they'd validate.