Interview Drills — Design Concepts (Craft Fluency)

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). These test whether you can articulate the craft clearly — IA, flows, fidelity, heuristics, hierarchy, accessibility, design systems, and Figma. Practice thinking aloud, define the term, then ground it in a concrete example. The app can role-play these as mock interviews (see mock-interview.md).

The universal concept-answer structure: Define the concept in one plain sentence → say why it matters (the user/business problem it solves) → give a concrete example → name the trade-off or how you'd know it's working. Avoid jargon-as-answer; show you understand the why, not just the vocabulary.

D1

difficulty: easy
concept: information-architecture What is information architecture, and how do you know whether a product's IA is good?
Framework: Define IA in plain terms → explain why it matters (findability) → name the methods you'd use to get it right (card sorting, tree testing, user-language labels) → state the signal of success.
Model answer: "IA is how you organize and label content so people can find what they need — the menus, categories, and structure under the surface, like clear aisles and honest signs in a supermarket. It matters because bad IA means users hunt through five menus and give up. To get it right I'd run a card sort to see how users group things, label in their words not internal jargon, and validate with tree testing. I know it's good when people find a target on the first try without backtracking, and findability metrics like search-then-give-up rates drop."
Rubric: Strong answers define IA as organization + labeling for findability, tie labels to the user's vocabulary, and name a validation method (card sort / tree test) plus a success signal. Weak answers conflate IA with visual design or sitemaps-as-deliverables, and offer no way to tell good from bad.

D2

difficulty: easy
concept: fidelity Walk me through the levels of fidelity, and how you decide which one to use.
Framework: List the progression (sketch → wireframe → mockup → prototype) → explain what each is for → state the rule that ties fidelity to the question being asked → give the cost/feedback rationale.
Model answer: "I increase fidelity gradually: sketches to explore many ideas fast, wireframes (grey boxes, placeholder text) to nail structure and content, mockups for the real visual look, and prototypes to make it clickable and testable. The rule is to match fidelity to the question I'm asking — show a grey wireframe and people comment on structure; show a polished mockup and they fixate on 'I don't like the blue.' I stay low-fi while questions are about flow and content because rough ideas are cheap to change, and only polish once the structure is settled."
Rubric: Strong answers name all levels in order, explain why low-to-high (cheap iteration, focused feedback), and connect fidelity choice to the question/stage. Weak answers just list tools, treat high fidelity as 'better,' or can't explain why you'd ever stay rough.

D3

difficulty: medium
concept: user-flows A stakeholder asks why you spend time mapping user flows instead of just designing the screens. How do you respond?
Framework: Define a user flow → explain what mapping it reveals before you design → give a concrete flow example → name the failure mode it prevents → tie to friction reduction.
Model answer: "A user flow is the step-by-step path someone takes to hit a goal — for 'book an appointment': open → search → pick provider → choose time → confirm. I map it first because the flow reveals how many steps a task takes, where people might get stuck or hit a dead end, and which screens I actually need to build. Designing screens first leads to pretty screens that don't connect into a sensible journey, then expensive rework. Seeing the whole path also lets me cut steps and reduce friction — every extra step loses some people — before any pixels exist."
Rubric: Strong answers define the flow, name what it surfaces (step count, sticking points, required screens) and the rework it prevents, and connect to friction. Weak answers treat flows as bureaucratic overhead or can't articulate what the map reveals that screens alone don't.

D4

difficulty: medium
concept: heuristics Name a few usability heuristics and show how you'd apply one to a real interface.
Framework: Briefly say what heuristics are and their role → list several well-known ones → pick one → apply it to a concrete screen with a before/after → note that heuristics complement but don't replace testing.
Model answer: "Heuristics are rules of thumb for good interfaces — useful ones include visibility of system status, match the real world, consistency, error prevention and recovery, and recognition over recall. Take visibility of system status: if a checkout button does nothing visible for two seconds after a tap, users re-tap and double-order. Applying the heuristic, I'd show an immediate loading state and a clear confirmation, so the user is never left wondering. I'd use heuristics like this to catch obvious issues early, but they don't replace watching real users — they just reduce what testing has to find."
Rubric: Strong answers name several real heuristics correctly, apply one concretely with a fix, and acknowledge heuristics support rather than replace usability testing. Weak answers list buzzwords without applying any, or treat a heuristic review as a substitute for testing with users.

D5

difficulty: medium
concept: visual-hierarchy-accessibility How do you create visual hierarchy, and how does accessibility — especially color contrast — constrain your choices?
Framework: Define visual hierarchy → name the tools that create it (size, color/contrast, position/spacing) → give the 'squint test' → bring in accessibility/contrast as both a readability and legal/ethical requirement → resolve the tension between a striking look and accessible contrast.
Model answer: "Visual hierarchy arranges elements so the eye knows what's most important and where to look first — I build it with size (big headline vs. small body), color and contrast (a bright accent button against a muted background), and position/spacing (top and isolated elements draw the eye). A quick check: squint at the screen — what still stands out should be the most important thing. Accessibility constrains this: light-grey text on white may look elegant but fails contrast and excludes low-vision users, so I hold text to sufficient contrast ratios — it's increasingly legally required. When 'on-brand but subtle' collides with readable, readable wins; I find an accent that's both high-contrast and on-brand rather than sacrificing legibility for aesthetics."
Rubric: Strong answers define hierarchy, name the three levers (size, contrast, position), include a practical check, and treat contrast/accessibility as a real constraint with the trade-off resolved toward readability. Weak answers describe 'making it pretty,' ignore accessibility, or treat contrast as optional polish.

D6

difficulty: hard
concept: design-systems-figma What's the difference between a component and a design system, and how do they keep design consistent at scale in Figma?
Framework: Define a component (and instance/master linkage) → define a design system as the level up (component library + tokens/styles + guidelines) → explain the consistency-and-speed-at-scale payoff → connect to the 'don't repeat yourself' instinct → note the new-designer reality of using and contributing to an existing system.
Model answer: "A component in Figma is a reusable element you design once — say a button — where every instance stays linked to the master, so changing the master updates them all at once. A design system is the level up: a shared library of those components plus style definitions (the official colors, fonts, and spacing values, often called tokens) and guidelines for when to use each piece — Google's Material Design is a well-known example. Together they give consistency and speed at scale: with hundreds of screens, keeping them consistent by hand is impossible and changing one color would mean editing thousands of elements, so reuse is the same 'don't repeat yourself' instinct as engineering. In practice, as a newer designer I'd mostly use and contribute to an existing system rather than invent one — pulling from the shared kit so the product feels unified no matter who designed which screen, and flagging gaps to extend it."
Rubric: Strong answers cleanly separate component (reusable, master-linked element) from design system (library + tokens + guidelines), explain the master-updates-instances mechanic, and articulate consistency + speed at scale with the DRY analogy. Bonus for the use-and-contribute reality. Weak answers blur the two terms, can't explain why reuse matters at scale, or describe a design system as just 'a set of screens.'