Product Designer interview prep

Short answer: Design thinking is a human-centered, iterative approach to problem-solving that starts from user needs rather than a ready-made solution. The IDEO / Stanford d.school model has five non-linear phases.

In depth:

1. Empathize — understand users through interviews, observation, and immersion, setting aside your own assumptions.
2. Define — synthesize observations into a clear problem statement and POV (e.g. 'busy parents need a faster way to… because…').
3. Ideate — generate a wide range of ideas without early judgment; quantity before quality.
4. Prototype — build cheap, fast, low-fi representations to make ideas tangible.
5. Test — put prototypes in front of users, learn, and loop back.

Empathize → Define → Ideate → Prototype → Test
    ^                                       |
    └────────── iterate: test → back ───────┘

What interviewers want to hear: it's iterative (testing sends you back to ideate), it's bias toward action (prototype to learn rather than debate), and it's about falling in love with the problem, not your solution. Be honest about limits: it's a mindset and toolkit, not a rigid recipe, and it pairs with the Double Diamond and Agile. I use it most for ambiguous 0→1 problems.

⚠️ Common mistake: treating the five phases as a linear waterfall you run exactly once.

Short answer: The terms come from Don Norman's The Design of Everyday Things. An affordance is a relationship between an object and a user that defines a possible action (a button affords pressing, a slider affords dragging). A signifier is the perceivable cue that communicates that affordance — where and how to act.

In depth:

1. Why distinguish them — the "Norman door": a door can afford pushing, but a handle (signifier) says "pull." The mismatch between signifier and affordance is what confuses people.
2. In UI affordances are mostly conventional, not physical — we lean on the user's learned conventions.
3. The modern risk — flat design and "mystery meat" navigation strip signifiers: without borders, shadows, and labels, users can't tell what's clickable.
4. The fix — keep enough signifiers: hover states, cursor changes, subtle elevation, clear labels.

/* signifiers: perceivable cues that reveal the affordance */
.button    { box-shadow: 0 1px 2px rgba(0,0,0,.2); cursor: pointer; } /* looks pressable */
.link      { color: #2563eb; text-decoration: underline; }           /* signals "this is a link" */
.draggable { cursor: grab; }                                          /* draggable */
.input     { border: 1px solid #cbd5e1; }                             /* box → "type here" */

⚠️ Common mistake: conflating affordance and signifier. The affordance is the possible action; the signifier is the cue that it exists — and in digital UI the signifiers are what carry the load.

Short answer: An MVP — minimum viable product — is the smallest version that delivers real value and lets the team learn whether the core hypothesis holds, with the least effort. The emphasis is on "viable": it must genuinely solve the problem, not be a broken half-product.

In depth:

1. The skateboard analogy (Henrik Kniberg) — if the goal is transportation, ship skateboard → bike → car, each usable end-to-end, not wheel → chassis → unfinished car.
2. Anchor on the single core job and the riskiest assumption to validate; cut everything else.
3. MoSCoW — to separate must-haves from "later."
4. Protect a baseline of quality and usability — "minimum" is about feature breadth, not craft. A clunky MVP gives a false negative: users churn for unrelated reasons.
5. Design the full vision first, then deliberately decide what to defer — so the MVP is a coherent slice of a known whole.

Wheel → Chassis → Car          ✗  nothing works until the end
Board → Bike    → Car          ✓  usable at every step

⚠️ Common mistake: confusing "minimum" with "low quality." The output of an MVP is learning — so it must be instrumented.

Short answer: Figma is my primary tool and the industry default: real-time collaboration, components/variants, auto layout, variables/tokens, prototyping, and dev-mode handoff in one place. I choose the tool by the job, not the other way around.

In depth:

1. UI & design systems — Figma for design, libraries, and most prototyping.
2. Discovery — FigJam/Miro for workshops, journey maps, affinity mapping, card sorting.
3. Hi-fi prototypes — ProtoPie or Framer when interactions need real logic, variables, or device sensors.
4. Research & testing — Maze/UserTesting for usability, Dovetail for synthesis.
5. Accessibility — Stark and contrast checkers plus real screen-reader testing.

The principle: the tool serves the question — I don't over-invest fidelity early and only escalate when the interaction quality itself is what's being validated.

⚠️ Common mistake: confusing tool fluency with design thinking — fluency is table stakes; the thinking matters more than the tool.

Short answer: First check what your agreement actually allows, and ask the former employer if you're unsure. Then show the thinking without the confidential parts: anonymize the company and data, recreate or abstract the screens, and give outcomes in relative terms. Saying "this is under NDA, so I've changed X" signals professionalism, not weakness.

In depth:

1. Know the boundary — contracts differ: some forbid any screens, others only unreleased work or customer data. Already-public, shipped UI is usually less risky to show than internal tools or roadmaps — but the contract decides, not your guess.
2. Anonymize — remove the company name, logos, customer names and real data; replace them with realistic dummy content.
3. Recreate or abstract — redraw key screens as simplified wireframes or in a different visual style, or show process artifacts (flows, sketches, synthesis) instead of finals.
4. Relative numbers — "conversion up 18%" or "support tickets down by about a third" instead of absolute revenue or user counts.
5. Control access — a password-protected case or a live walkthrough without handing over files; never send confidential files after the interview.

⚠️ Common mistake: showing confidential screens "just in the interview" — a panel that watches you break one NDA assumes you'd break theirs.