Product Designer interview prep

A grid and a spacing system replace arbitrary pixel decisions with a shared rhythm, which is what makes an interface feel calm and 'designed' rather than improvised. An 8-point grid means all spacing, sizing, and positioning are multiples of 8 (8, 16, 24, 32…), sometimes with a 4px sub-step for fine adjustments like icon padding. Why 8: it divides cleanly across common screen densities (1x/2x/3x), it limits choices so spacing stays consistent, and it scales predictably. Layout grids — typically 12 columns for web because 12 divides into halves, thirds, quarters, and sixths — give a structure for aligning content and make responsive breakpoints rational. The real value is constraint: when a team can only pick from 4/8/16/24/32, components naturally align and whitespace becomes intentional. I pair this with a spacing scale exposed as tokens (space-1 = 4, space-2 = 8…) so designers and engineers speak the same language. Inconsistent spacing is the single most common tell of an amateur interface; a system fixes it by default. Spacing also encodes hierarchy via the Gestalt law of proximity — more space between groups than within them.

Contrast is the perceptible difference between elements, and it's the primary tool for directing attention and ensuring legibility. People think of color contrast first — and that's critical for accessibility (WCAG AA wants 4.5:1 for body text) — but several kinds of contrast work together. (1) Size contrast — big vs small establishes hierarchy. (2) Weight contrast — bold against regular. (3) Color/value contrast — light vs dark, saturated vs muted. (4) Shape contrast — a pill button among rectangular cards stands out. (5) Spatial contrast — a dense area next to whitespace draws the eye to the open element. (6) Directional/orientation contrast. The principle: contrast creates focal points, so I use it deliberately on the one or two things that matter per screen and suppress it elsewhere. Too little contrast and everything blends into mush; too much and the screen feels chaotic and tiring. A frequent mistake is decorative contrast — high-contrast elements that aren't actually important — which fights the real hierarchy. I also verify contrast works for users with low vision and in different lighting (bright sunlight on mobile), which is why I never ship text below the contrast threshold even when it looks 'softer.'

Design thinking is a human-centered, iterative approach to problem-solving that starts from user needs rather than from a solution. The popular IDEO/Stanford d.school model has five non-linear phases: (1) Empathize — understand users through interviews, observation, and immersion, setting aside your own assumptions. (2) Define — synthesize observations into a clear problem statement and point of view (e.g., 'busy parents need a faster way to… because…'). (3) Ideate — generate a wide range of ideas without judging them early; quantity before quality. (4) Prototype — build cheap, fast, low-fidelity representations to make ideas tangible. (5) Test — put prototypes in front of users, learn, and loop back. The key ideas interviewers want to hear: it's iterative (you cycle back, e.g., 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. I'd also be honest about its limits — design thinking is a mindset and toolkit, not a rigid recipe, and it pairs with delivery frameworks like the Double Diamond and Agile. I use it most for ambiguous, 0→1 problems where the need itself is unclear.

They're complementary research-synthesis artifacts. A persona is a model of who: a fictional but evidence-based archetype representing a key user segment, capturing goals, needs, behaviors, pain points, context, and motivations — not demographics for their own sake. Good personas come from real research (interviews, data), not stakeholder imagination, and their job is to build empathy and align the team on who we're designing for so decisions become 'would this work for Maya?' instead of 'would I like it?' A journey map is a model of how and when: it visualizes the steps a persona takes to accomplish a goal across stages, capturing their actions, thoughts, emotions (often an emotion curve), touchpoints, and — most valuably — pain points and opportunities at each stage. Where a persona is a snapshot of a person, a journey map is a timeline of an experience. I use them together: I map a specific persona through a specific scenario. The real value of a journey map isn't the pretty artifact — it's surfacing the low points and gaps (e.g., a confusing handoff between support and self-service) that become prioritized design opportunities. I'm wary of both becoming decorative deliverables; they should drive decisions, or I don't make them.

They're points on a fidelity spectrum, each answering a different question. Wireframes are low-fidelity, usually grayscale skeletons focused on structure, layout, hierarchy, and content priority — deliberately ugly so the conversation stays on flow and function, not colors. They answer 'what goes where and in what order?' Mockups are high-fidelity static designs with real visual design — color, typography, imagery, branding — showing what a screen will actually look like, but not interactive. They answer 'how does it look?' Prototypes are interactive: linked screens or coded experiences that simulate real behavior — clicking, transitions, states — at low or high fidelity. They answer 'how does it feel/work?' and are what I put in front of users for usability testing because they reveal flow and interaction problems static screens hide. My workflow typically moves wireframe → mockup → prototype, increasing fidelity as confidence grows, so I don't polish pixels on a flow that might be wrong. But I match fidelity to the question: to test navigation logic, a clickable low-fi prototype is better (and cheaper) than a beautiful mockup. The principle is to invest the least fidelity needed to learn what I need to learn at each stage.