Interview Drills — Portfolio Walkthrough

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 portfolio walkthrough is the single most important design interview: you present a case study as a story and defend your decisions out loud. Practice narrating your capstone — not reading slides — and tie every choice back to a user and what you learned. The app can role-play these as mock interviews (see mock-interview.md).

The universal walkthrough structure: Problem (who, what, why it mattered) → Research (what you learned about users) → Process (flows, options you explored, the messy middle) → Solution (the final design and why) → Testing (what you watched, what broke) → Outcome (the result and what you'd do next). Lead with the story of your thinking, not the pretty screens.

D1

difficulty: easy
concept: portfolio-and-landing-the-job Walk me through one of your projects.
Framework: Set the stage in one line (what, who for, your role) → state the problem you were solving → research and the key insight → the process and options you explored → the final solution and why → what testing taught you → the outcome and next step. Keep it to ~5 minutes and narrate it as a story, not a feature tour.
Model answer: "I redesigned a clinic's booking app because patients gave up before finishing. My role: sole designer. I interviewed five recent users; the insight was that asking for insurance ID on screen one scared people off. I sketched several flows, chose one that defers ID to the end, prototyped it, and tested with five people — four booked without hesitation versus one before. If I shipped it, I'd watch the drop-off rate at the ID step. Want me to go deeper on the research or the final UI?"
Rubric: Strong answers follow the problem→research→process→solution→testing→outcome arc, stay concise, center a real user, and end by offering to go deeper. Weak answers jump straight to final screens, narrate every pixel, never mention users or testing, or ramble with no structure.

D2

difficulty: medium
concept: design-process-and-thinking What problem were you solving, and how did you know it was the right one?
Framework: State the problem as a sharp one-sentence statement (who + where they got stuck) → explain how you arrived at it (the "Empathize/Define" work before designing) → cite the evidence (research, not a hunch) → say what you deliberately chose not to solve. Show you defined the problem before drawing screens.
Model answer: "Problem statement: 'New users abandon onboarding because the first screen asks for too much, too soon.' I didn't start there — I started by watching five people sign up and counting where they dropped. The data said 60% quit at the ID step; interviews said it felt invasive. I scoped it to just onboarding and explicitly left the dashboard redesign out, because the bleeding was at the front door."
Rubric: Strong answers give a crisp problem statement grounded in research, show the define-before-design discipline, and name what was cut from scope. Weak answers describe a vague problem ("make it nicer"), justify it by personal taste, or reveal they jumped to screens before defining anything.

D3

difficulty: medium
concept: user-research-basics Walk me through your research. How did it change your design?
Framework: Name the method and why it fit (qual for "why", quant for "what/how many") → describe how you ran it well (real past behavior, open questions, no leading) → state the one or two sharp insights → show a concrete design decision each insight changed. The point is research that moved the design, not a report.
Model answer: "I combined analytics — 60% abandoned the form — with five interviews to learn why. I asked about the last time they booked anything, not whether they'd 'like' my idea, so I wasn't fishing for a yes. The sharp insight: people froze when asked for sensitive info before they trusted the app. So I moved ID collection to after they'd picked a slot and added a one-line reason for asking. That single change came straight from the interviews."
Rubric: Strong answers pair qual and quant, show sound interview technique (past behavior, no leading), distill sharp insights, and trace each to a specific design change. Weak answers list activities with no insight, describe research that didn't affect anything, or admit to leading/hypothetical questions.

D4

difficulty: medium
concept: design-process-and-thinking Show me the options you considered. Why this solution and not the others?
Framework: Prove you diverged (several real alternatives, not one idea dressed up) → state the criteria you converged on (user need, effort, the insight) → walk 2–3 options with an honest trade-off each → explain why the chosen one won on the criteria. Show the messy middle, not just the polished end.
Model answer: "I sketched three onboarding flows. Option A: keep one long form but add a progress bar — cheap, but didn't fix the trust problem. Option B: a chatty step-by-step wizard — friendly, but slow for repeat users. Option C: a short three-step flow that defers ID to the end. I chose C because my insight was about trust timing, not form length, and C addressed that directly with modest effort. I almost picked B for warmth, but it punished fast users."
Rubric: Strong answers show genuine divergence, name explicit selection criteria tied to the insight, and give honest trade-offs including why a tempting option lost. Weak answers present a single idea, show "options" that are trivial variants, or justify the choice with taste rather than criteria.

D5

difficulty: medium
concept: usability-and-testing How did you test this, and what did you learn? What would you change?
Framework: Describe a realistic task you gave real users → how you ran it right (~5 users, think-aloud, no rescuing) → the specific things that broke (where they hesitated, went wrong, or failed) → what you changed as a result → what you'd test or improve next. Treat the struggles as the valuable data.
Model answer: "I gave five people one task: 'book the earliest appointment.' I asked them to think aloud and bit my tongue when they got stuck. Two missed the date picker because it looked like static text — that hesitation was the gold. I gave it a clear tappable style and re-tested; both found it. If I had more time, I'd test the confirmation step, where one person wasn't sure the booking actually went through — a system-status gap I'd fix next."
Rubric: Strong answers use a real task, ~5 users, think-aloud, and no leading; surface concrete failures; and show iteration plus a humble "what's next." Weak answers claim "everyone loved it," describe no specific problems, admit to helping users, or treat testing as a formality with no design change.

D6

difficulty: hard
concept: portfolio-and-landing-the-job An interviewer pushes back: "I'd have just made the button bigger — why all this?" Defend your decision.
Framework: Stay calm and take the critique gracefully (don't get defensive) → restate the real problem to reframe the suggestion → explain why the surface fix doesn't address the root cause → back your decision with the user evidence → concede where they have a fair point and say how you'd validate. Defending well means reasoning, not stubbornness.
Model answer: "Fair challenge — a bigger button is the obvious first move. But the testing showed people weren't missing the button; they were abandoning earlier, at the ID request, because they didn't trust the app yet. A bigger button wouldn't touch that. The data pointed at trust timing, so I moved ID later. That said, you're right that button affordance mattered elsewhere — two users missed the date picker, and I did enlarge and restyle that. I'd validate both with a quick A/B on completion rate."
Rubric: Strong answers receive critique without defensiveness, reframe to the root problem, cite user evidence, and concede genuinely while proposing a way to validate. Weak answers get defensive, dismiss the interviewer, defend with opinion instead of evidence, or cave completely without reasoning — both extremes fail. Composure under pushback is the signal.