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: Shift the conversation from positions to the underlying needs and shared goal, re-center everyone on user evidence, and find a design solution that dissolves the false binary rather than settling for a worse compromise.

In depth:

1. Situation — a PM wanted maximum simplicity for new users; an account manager pushed advanced controls front and center. Conflicting visions for the same screen.
2. To the needs — I ran a short alignment session: the PM wanted activation, the AM wanted to retain high-value power users. Both legitimate, not mutually exclusive.
3. Anchor in research — we had distinct novice and expert segments; I reframed it as a design problem: progressive disclosure — a simple default view, advanced controls one tap away.
4. Validate — I prototyped and tested with both segments; it satisfied everyone. When no solution exists, I escalate to the decision-owner with a clear recommendation and tradeoffs rather than letting it stall.

Two positions → one need
─────────────────────────────────────────
PM: 'simpler'  ┐
               ├─► shared goal: value for
AM: 'more power'┘    both segments
                        │
                        ▼
         Progressive disclosure:
    [ simple view by default      ]
    [ advanced — one tap away      ]

⚠️ Common mistake: politically picking a side or splitting the difference into a solution worse than both — find the option that removes the false choice.