Senior UX Designer Interview Preparation Guide - Netflix

Direct answer

Persuading someone senior to fund or change something means leading with the decision you want, naming the cost of the status quo explicitly, pre-empting the single most likely objection before it's raised, and sizing the ask (a phased or capped version) so agreeing feels lower-risk than it would if you asked for everything up front.

Structured elaboration

Anatomy of an executive ask:

1. Lead with the decision, not the narrative. State the ask early; don't make the sponsor wait for the punchline.
2. Name the cost of inaction explicitly, not just the benefit of acting.
3. Pre-empt the most likely objection (revenue impact, cost, risk) before someone else raises it in the room.
4. Size the ask to reduce perceived risk: a phased rollout, a pilot, or a capped budget is an easier yes than the full commitment.
5. Know your sponsor and your skeptic beforehand, and align the skeptic privately when possible.

Same competency, different scale. This shows up from small asks to board-level ones:

Worked example

Situation. At a mid-size company, an engineering manager proposed a platform consolidation project in a leadership review. A senior VP publicly dismissed it in the room as "solving a problem nobody has," undermining the pitch in front of the same audience needed for approval.

Stakes. Losing credibility with that VP risked not just this proposal but every future ask; meanwhile the underlying problem (duplicated infrastructure, rising support cost) was real and getting worse.

The influence moves.

• Didn't re-litigate in the room; took the public pushback as a signal to gather sharper evidence, not an invitation to argue live.
• Went back to the VP one-on-one, not to reopen the room's discussion but to ask directly what would change their mind, and learned the real objection was a past project's failed ROI, not this one's merits.
• Rebuilt the case to address that exact objection: capped the initial ask to a bounded pilot instead of the full six-month rewrite, with a defined stop-loss checkpoint.
• Brought the VP back in as a named reviewer of the revised plan, rather than resurfacing it as a surprise.

Resolution. The VP co-sponsored the revised, phased version at the next review. The earlier public criticism ended up making the final plan tighter and more credible, not dead.

What a senior candidate does differently. Doesn't treat public pushback as the end of the story or take it personally; treats it as the clearest possible signal of the real objection and goes to address it directly with the person who raised it, rather than only preparing a better slide for the same room.

Trade-offs and pitfalls

• Sequencing matters. Leading with the ask before the sponsor is aligned invites exactly this kind of public pushback; senior candidates often pre-wire the most skeptical stakeholder before the room, not after.
• Sizing matters. Asking for the full multi-month or multi-million commitment up front is a harder yes than a capped pilot with a defined checkpoint; the same case is more persuasive staged.
• "Strategic value" still needs a quantified comparison. Even initiatives without near-term revenue need some measured comparison (opportunity cost, cost of inaction), or the ask reads as a hunch.

Experiment overview (goal)
Compare ROI of collaborative design workshops vs. solo design on quality, speed, and business impact over 8 weeks.

Experimental design

• Randomized A/B within comparable feature work: Team A runs 4 collaborative workshops (kickoff, ideation, prototype review, handoff) per feature; Team B follows solo-design process with same checkpoints.
• Run across 6 similar-scope features/products or 2 quarters to reach power.

Measurable outcomes

• UX metrics (leading): task success rate, time-on-task, SUS/NPS change, number of usability issues found in validation testing.
• Process metrics: design cycle time (days from brief to final spec), rework hours, number of design iterations.
• Business metrics (lagging): activation rate, conversion lift, retention delta, support tickets related to the feature.
• Cost metrics: designer hours, stakeholder time, facilitation cost.

Sampling & analysis

• Recruit 30–50 users per feature for usability tests; ensure stratified sampling by persona.
• Use t-tests / ANOVA for continuous metrics and chi-square for categorical; compute effect sizes and ROI = (incremental business value − incremental cost) / incremental cost. Report confidence intervals and p-values; pre-register success thresholds.

Communication plan for speed-focused stakeholders

• In 1 slide: headline ROI, one-line recommendation, and projected time-to-value.
• 1-page appendix: key metrics, CI, and cost breakdown.
• Quick wins: highlight where workshops reduced rework or sped delivery. Offer a pilot cadence (2 workshops) as low-cost experiment to scale.

Direct answer
Structure the documentation with the terms people actually get confused by first, before the full reference, and for each term give the plain definition, why it matters to that reader, and one concrete worked example. That combination, not the structure alone, is what makes technical documentation usable for a non-technical reader.

Structured elaboration

• Order matters: most readers stop after hitting the first term they don't understand. Front-load a short glossary of the terms that actually cause confusion, before the detailed field-by-field reference.
• For every term, write three things: the plain-language definition, why it matters to this reader, and one worked example row. A definition alone leaves edge cases unresolved.
• Choosing what to omit: document only the fields that cause confusion or drive a decision. A runbook for a non-technical on-call coordinator doesn't need the retry logic, only what to check and who to page.
• Checking for understanding without condescending: walk one real stakeholder through the doc live and watch where they hesitate or reread. That's a more honest signal than asking "does this make sense?", which invites a polite yes.

Worked example
A metrics glossary entry for "conversion":

• Jargon: "conversion = distinct user_id where event_type = 'purchase', grouped by session_id, within a 30-day attribution window."
• Plain: "Someone counts as 'converted' if they buy something within 30 days of first visiting, even if they don't buy on that first visit. Someone who browses in January and buys in February still counts as one conversion, attributed to February."
• Analogy: like a store crediting a sale to whichever week the customer actually paid, not whichever week they first walked in and looked around.
• Where it breaks: if a stakeholder assumes this tells them how well an ad campaign performed the week it ran, the honest answer is no, the 30-day window can attribute a sale to a much later week than the campaign that drove it. That caveat has to be stated explicitly, not smoothed over by the analogy.

Trade-offs and pitfalls
A glossary with definitions but no worked examples still leaves readers guessing at edge cases, like the January-to-February attribution above. Over-documenting every field buries the handful of terms people actually ask about. Asking "does that make sense?" gets a polite yes even when it doesn't land; watching someone actually use the document is more honest feedback. A realistic sign the documentation worked is fewer repeat "what does X mean" questions in the following review meetings, not a specific measured percentage, that number isn't something you can honestly claim to have tracked unless you actually counted it.

Direct Answer

I gave them real leadership surface area before the title changed, not a reading list, running part of a meeting, owning a small project end to end, giving feedback to a peer, so what I was actually assessing was how they behaved with authority, under pressure, and with imperfect information, not just whether they said the right things about leadership.

Framework

What "prepare them" actually meant in practice: shadowing with a handoff rather than just observing, where they ran part of a 1:1 or a triage themselves with me present, then we debriefed; a bounded leadership trial, owning something small end to end, planning, coordinating with others, being the point of contact, with a real but limited blast radius if it went wrong; deliberate exposure to the parts of the job that aren't visible from the IC seat, prioritization tradeoffs, giving feedback that isn't well received, defending a decision to someone who disagrees; and a structured way to reflect on each of these, naming what they learned so it generalized beyond the specific situation.

To evaluate whether it was working, I looked for changes in how they handled ambiguity and pushback specifically, since that's the part of leadership hardest to fake or coach quickly: did they make a call and hold it under mild disagreement, or fold immediately; did they proactively flag a risk before being asked, or wait to be told.

Worked Example

Someone technically strong on my team wanted to move toward tech lead. Rather than a development-plan document, I gave them ownership of a real but contained piece of work: they ran planning for it, coordinated with the two other people involved, and I stayed available but stepped back from decisions I'd normally have made. The useful moment wasn't when it went smoothly, it was when a dependency slipped and they had to renegotiate scope with someone more senior than them. Watching how they handled that, calmly, with a clear ask rather than an apology, told me more than months of 1:1s about how leadership would actually work when the stakes went up.

Trade-offs and Pitfalls

• Giving someone the title before the trial, rather than the trial before the title, removes the one thing that actually tells you whether they're ready.
• Staying too involved during the trial defeats the purpose. Making every call for them evaluates your own judgment, not theirs.
• Not protecting their existing technical credibility during the transition, letting their technical skills visibly atrophy while they're still proving themselves as a leader, can undercut trust from the team they're about to lead.
• A senior answer describes a real trial with a moment of pressure in it; a junior answer describes a training plan with no evidence anyone was actually tested.

Approach & goals
I’d deliver a pragmatic, prioritized audit that produces clear remediation tickets: identify high-impact accessibility barriers, fix them fast, and enable engineers with precise design annotations.

Step 1 — Automated plugin sweep (Day 1)

• Run Figma/Sketch plugins (Stark, Able, Axe via Storybook/Chromatic) to output: contrast failures, missing alt text, contrast ratios, and aria label gaps.
• Export a CSV/list of findings grouped by severity (WCAG A/AA/AAA) and screen/component.

Step 2 — Manual verification & keyboard-only testing (Day 1–2)

• Keyboard audit: Tab order, focus visibility, logical focus flow, trapped modals. Record clips/GIFs of failures.
• Screen reader audit: Test with NVDA/VoiceOver on representative flows (signup, checkout, nav). Note missing labels, incorrect reading order, and landmark issues.

Prioritization matrix

• Priority 1 (Critical): keyboard traps, unlabeled interactive icons, missing form labels, primary CTAs invisible to screen readers, contrast < 3:1 on text >18pt or important UI.
• Priority 2 (High): inconsistent focus states, contrast 3:1–4.5:1 on body text, decorative icons lacking role/presentation.
• Priority 3 (Medium): aesthetic focus style tweaks, non-critical imagery captions.

Annotating designs for engineering

• Create a consolidated audit Figma file with pages: Findings, Suggested fixes, Component tokens.
• For each issue add:
  • Comment with expected ARIA/HTML (e.g., button role, aria-label="Search", tabindex=0).
  • CSS token suggestion (focus outline: 3px solid var(--brand), focus-visible rules).
  • Contrast math: current color + suggested replacement swatch and hex.
  • GIF proving the bug and acceptance criteria (e.g., “Tab enters header, focus visible, SR announces ‘Main navigation’”).
• Link to WCAG success criteria and example code snippets.

Tracking remediation

• Create Epic in backlog: Accessibility Audit Q1. Break into issues per component with tags: accessibility, priority, designer-owner.
• Each ticket includes: Figma link, screenshot/GIF, acceptance criteria, test steps, and estimated dev effort.
• Require QA checklist and a PR template that references the ticket and includes automated accessibility test output.
• Weekly triage with PM/Engineering to unblock critical fixes; measure progress with dashboard (open vs closed by priority) and aim to close all P1s within one sprint.

Outcome
This produces reproducible, prioritized fixes, reduces developer ambiguity, and embeds accessibility into delivery cadence.

Situation: While designing a checkout flow for a subscription product, a product manager and an engineering lead pushed back: they felt the new multi-step flow increased drop-off risk and delayed launch.

Task: My goal was to evaluate the feedback, validate whether the design harmed conversion or UX, iterate the design, and align stakeholders on the final approach.

Action: I synthesized feedback by categorizing concerns into usability, technical risk, and business metrics. I ran a rapid 3-hour prototype test with five target users and reviewed analytics from the existing flow. Findings showed users valued clarity around pricing and trial terms—so the extra step improved comprehension but could be streamlined. I produced two iterations in Figma: (A) a condensed single-page variant with inline pricing explanations, and (B) a hybrid two-step with progressive disclosure. I presented both to stakeholders with test clips, quantitative notes (time-on-task, comprehension), and a recommended experiment plan (A/B test). We agreed to implement the hybrid as a controlled rollout.

Result: The hybrid rollout increased comprehension by 30% in our usability metrics and kept conversion flat while reducing support tickets about billing. Stakeholders appreciated the evidence-based trade-offs.

Contrast: A junior might defensively revise the design immediately; I demonstrated a senior approach—validating, weighing metrics, proposing measurable experiments, and communicating trade-offs clearly.

Direct answer. A long analytics dashboard with multiple widget panels needs a landmark structure that lets a screen reader user jump directly to the section they want, rather than tabbing or reading through the entire page linearly: a <main> landmark for the dashboard content, <section> elements with aria-labelledby pointing at each panel's visible heading, and a consistent heading hierarchy that reflects the panel structure.

Structure.

<main aria-label="Sales dashboard">
  <h1>Sales Dashboard</h1>
  <section aria-labelledby="revenue-heading">
    <h2 id="revenue-heading">Revenue</h2>
    ...
  </section>
  <section aria-labelledby="retention-heading">
    <h2 id="retention-heading">Retention</h2>
    ...
  </section>
</main>

Each <section> becomes a navigable landmark region (announced with its accessible name from aria-labelledby) in a screen reader's landmark-navigation list, letting a user jump straight to "Retention" without passing through every widget above it.

Heading hierarchy. One <h1> for the whole dashboard, <h2> for each panel, and <h3> for any sub-groupings within a panel (e.g. a panel with two related charts), never skipping a level (going from <h2> straight to <h4>), since screen reader users commonly navigate by heading level and a skipped level breaks the implied structure they're relying on.

Representing this in Figma. Figma has no native concept of landmark roles or heading levels, so the structure has to be represented explicitly, not left implicit in visual grouping: name each frame/layer to mirror the intended element and level directly (e.g. "H1 - Sales Dashboard," "Section: Revenue (H2)"), and mark each landmark's boundary with a dedicated annotation layer or an accessibility-annotation plugin (Stark, or Figma's built-in dev-mode annotations) so a developer can see the intended aria-labelledby target and landmark boundary without inferring it from a card's drop shadow or spacing alone.

Developer handoff. The handoff spec should be an explicit table, not just the visual design file: for every landmark, list its element/role, the accessible-name source (the heading id it's labelled by), and its heading level, so engineers aren't left inferring structure from font size and spacing. Call out the never-skip-a-level rule explicitly in the handoff notes, since heading level is a purely visual choice in Figma (font size and weight) that an engineer building from the file alone could easily misread as any level.

Trade-offs and pitfalls. A common real mistake on data-dense dashboards is treating every widget as its own <section> with no landmark label at all, which technically creates navigable regions but leaves them all announced generically as "region" with no distinguishing name, giving a screen reader user a long list of identical-sounding stops with no way to tell them apart without entering each one; the aria-labelledby connection to a real visible heading is what makes the landmark list actually useful rather than just technically present.

Direct answer

For something this small, fidelity should track risk, not polish. The visual design barely matters and can stay low-fidelity, but the state and timing behavior is the actual product, so that part needs to feel real, real typing, real delays, real error states, before tooling gets decided.

Structured elaboration

Start from the state machine, not the screen

Before opening a design tool, sketch the states the field can be in and what moves it between them: idle, editing, saving, saved, error, and a cancel path back out of editing. Naming these up front surfaces edge cases early (what happens if the user starts a second edit while the first is still saving, what does cancel revert to) and gives engineering a shared vocabulary before any pixels exist.

stateDiagram-v2
    [*] --> Idle
    Idle --> Editing: click field
    Editing --> Validating: blur or debounce
    Validating --> Saving: valid input
    Validating --> Error: invalid input
    Error --> Editing: user corrects
    Saving --> Saved: server ack
    Saving --> Error: request fails
    Saved --> Idle: after confirm
    Editing --> Idle: cancel or escape
    Error --> Idle: discard

In the diagram, "debounce" means waiting for a short pause after the user stops typing before triggering validation, instead of reacting to every keystroke or waiting only for the field to lose focus (blur).

Decide fidelity per concern, not for the whole prototype

• Visual: static mockups of each state are enough; there's no real ambiguity to resolve visually.
• Timing and motion: needs an interactive prototype with real transition delays, since timing is exactly what's being validated and can't be judged from a static frame.
• Copy and error states: needs real, specific validation and error text, since testing whether people understand why something failed requires the actual words, not placeholder copy.
• Tooling follows from that split: an interactive click-through prototype covers the timing and flow without needing real code or a live backend. The saving delay and error branch can be faked with a timer and a toggle.

Worked example

Build three linked frames per state, wire idle to editing on click, editing to a fake-saving state with a short, perceptible delay (long enough to notice, short enough to feel like autosave rather than a manual save action), and a branch to error with realistic copy such as "Couldn't save, check your connection" rather than a generic error label. Test with 5-6 participants doing a task that requires editing the field at least twice: once with the fake network slowed, once with an invalid value entered. Watch for whether they notice the save happened without hunting for confirmation, whether they trust it enough to navigate away mid-save, and whether, on error, they understand if their edit was lost or just not saved yet.

Trade-offs and pitfalls

• Skipping the state sketch and going straight to a polished mockup is the classic mistake at this scale: it produces a good-looking artifact that quietly omits the cancel-during-save or double-edit case, which only surfaces during build.
• Over-investing in visual fidelity for a component this small wastes the resource that's actually scarce: time to test the timing and error behavior against real users.
• Testing this component in isolation is faster, but a field embedded in a longer real task is what a shipped autosave interaction has to survive: interruptions, navigation, multitasking. Isolated testing is fine for a directional read; if the risk is high, test it inside the real flow it lives in.

Contextual field research — 4 advantages

• Real-world behavior: observes actual shopping flows, distractions, and workarounds (e.g., aisle switching for deals).
• Environmental cues: captures shelf layout, signage, lighting that affect decisions.
• Social context: sees influence of companions, staff, or in-store promotions.
• Rich qualitative artifacts: photos, audio, receipts, and immediate follow-up questions yield grounded insights.

Contextual field research — 4 disadvantages

• Low control: hard to isolate variables (promotions, stockouts).
• Time and cost: travel, recruitment, store permissions, and scheduling.
• Observer effect: shoppers may change behavior if noticed.
• Data variability: noisy data hard to compare quantitatively.

Lab usability testing — 4 advantages

• Experimental control: manipulate UI, tasks, and stimuli precisely (e.g., compare basket flows).
• Repeatability: standardized tasks enable A/B comparisons and metrics.
• Rich instrumentation: screen capture, eye-tracking, think-aloud for micro-interaction insights.
• Faster iteration: prototype changes tested quickly with recruited participants.

Lab usability testing — 4 disadvantages

• Low ecological validity: lacks in-store stimuli (crowds, shelf layout).
• Artificial tasks: participants may behave differently than real shoppers.
• Limited context: cannot observe physical constraints like cart size or product handling.
• Recruitment bias: lab sample may not represent typical grocery shoppers.

Hybrid study design (proposal)

• In-lab “simulated store” sessions with real physical artifacts: recreate a single aisle with real packaging and signage; participants perform a shopping task using a prototype mobile feature while wearing eye-tracking and think-aloud.
• Follow each session with a scheduled short in-store shadowing (same participant) within 48 hours to validate choices and observe contextual differences.
• Combine quantitative metrics (task time, errors, eye fixation) with field notes and photos; iterate prototypes between waves.
  This balances ecological validity with control and enables triangulation of behavior.

Direct answer

Three practical fixes: lighten the brand color specifically for dark-mode body text via a dedicated token, reserve the brand color for non-text roles (accents, icons, borders) and use a separate accessible neutral for body text, or place text on an elevated/layered surface that raises contrast without touching the brand color itself. Each trades off visual fidelity, brand-requirement adherence, and long-term maintainability differently, and the right choice depends on how central the exact brand hue is to that specific surface.

Structured elaboration

The three approaches compared

How to decide

Ask which constraint is least negotiable for this specific surface. If the brand color's exact hue in body text is not actually load-bearing for brand recognition (most brand guidelines care about logos, key surfaces, and primary actions, not body copy), the first approach is usually the lowest-effort fix. If a stakeholder insists the literal brand hex must never change under any circumstance, the second or third approach avoids touching the color at all, at the cost of either reduced brand presence in text-heavy areas or added implementation complexity for elevation.

Worked example

Brand primary is #0052CC used as body text on a dark-mode surface #121417. Using the standard WCAG relative-luminance and contrast-ratio formulas:

Computing this for the two colors (sRGB channels converted to linear, then combined into relative luminance) gives:

#0052CC at 2.705:1 fails the 4.5:1 requirement for normal body text, confirming the scenario. Approach one (token-level lightening) resolves it concretely: shifting to #4C8DFF for the dark-mode text-brand token reaches 5.765:1, comfortably passing AA, while staying in the same blue hue family so it still reads as "the brand blue."

Applying approach two instead: body text would move to a neutral like #E8EAED on the same #121417 surface (a near-white on near-black pairing, well above the 4.5:1 threshold by construction, since neutral grayscale pairs are the easiest combination to push past any contrast target), and #0052CC would be kept for icons, links, and the primary button surface only, where a 3:1 graphical-object threshold applies rather than the stricter 4.5:1 text threshold.

Trade-offs and pitfalls

• A common wrong turn is lightening the color "by eye" without checking the resulting ratio; the fix must be verified against the actual formula or a contrast-checking tool, not approved on the assumption that "lighter obviously means more contrast," since hue and saturation shifts can move luminance less than expected.
• Reserving the brand color for non-text roles only works if there is a lint rule or design-token structure that actually prevents color.brand from being used as a text-color token; without enforcement, the next contributor reaches for the "obvious" brand color for a new text use case and reintroduces the same failure.
• The layered-surface approach preserves brand fidelity perfectly but is the most expensive to maintain consistently, since every component that wants to show brand-colored text now needs an elevation treatment behind it, not just a token swap; reserve it for cases where the brand color truly cannot change.
• Whichever fix is chosen, it must be re-verified specifically for interactive states (hover, focus, disabled), since a color that passes at rest can drop below threshold when opacity is reduced for a disabled state.