Netflix Entry-Level UX Designer Interview Preparation Guide

Direct answer. Compare what the feature costs to keep with what is at risk if it goes, using revenue, not just user counts. Sunset (retire the feature) only if the cost clearly exceeds the risk and a migration path exists. Then handle the vocal minority with notice, alternatives, and honesty, rather than surprise.

Evidence to collect.

1. Who the 4% are: plan, revenue, contract terms, and whether they are strategic accounts. Illustratively, with 50,000 monthly active users (MAU: users active in a month), 4% is 2,000 users.
2. How they use it: frequency, and whether it is a core workflow or an occasional one.
3. What it costs us: engineering time and release delay. If it consumes 15% of an 8-engineer team, that is 8 x 0.15 = 1.2 full-time equivalents (FTE: one person's full working time); at an illustrative $180k loaded cost (salary plus benefits, tools and overhead) that is 1.2 x 180,000 = $216k a year.
4. Revenue at risk: if 300 of the 2,000 users are paying $40/month, annual revenue is 300 x 40 x 12 = $144k. At 30% churn on removal, $43k is lost; at 60%, $86k.
5. Alternatives: whether the main product or a partner covers their need.
6. Dependencies: integrations, contracts, public commitments.

Decision. Here the carrying cost ($216k) exceeds even the pessimistic loss ($86k), so sunset is defensible, provided the strategic accounts are checked individually. Test that comparison before trusting it. The $216k is only a saving if the 1.2 FTE is redeployed to work with a payoff, and sunsetting has its own one-time costs (migration tooling, support load during the notice period, possible refunds or credits) that should be netted against it. The loss side is also only the direct revenue: it leaves out accounts that leave the whole product because of this feature, so the 30% to 60% churn range is an assumption to test with the top accounts, not a measurement.

Two other situations call for a different decision. If the feature had weak adoption from the start, the choice is iterate (improve it), pivot (repurpose it for a different job) or sunset: iterate if targeted users love it but few find it, pivot if usage is real but for a different job, sunset if neither. If you have run usability testing, the choice is keep, redesign or remove: keep if tasks succeed, redesign if users want the job done but struggle, remove if they ignore it.

Handling the vocal minority.

• Talk to them first and learn their real workflow.
• Give at least a notice period with a dated timeline, an export, and a migration guide. Sample wording: "On 1 March we will retire Reports Builder. It keeps working until 1 June, three months from now. You can export everything with the Export button today, and here is how to get the same result in the main dashboard. If this breaks a workflow, reply to this email by 15 March and we will talk."
• Offer a workaround or partner tool; pause for the few high-value accounts if justified.
• Publish a short, honest rationale, and reply to feedback.

Pitfall. Loud is not the same as large, and quiet is not the same as unimportant. Check revenue concentration before deciding.

Direct answer

A reviewer flagged that a screen I designed was hard or impossible to use with assistive technology, for example low color contrast, a keyboard flow that trapped focus, or missing labels a screen reader could announce. I treated the critique as a real usability bug, not a style note: I reproduced the problem myself using the same tool the reviewer used, fixed the underlying pattern rather than the one instance, validated the fix with the actual assistive technology, and changed the team's review process so the same category of problem gets caught before it ships again.

Structured elaboration

Accessibility critique usually falls into one of three buckets, and each needs a different validation method:

• Color contrast: the Web Content Accessibility Guidelines (WCAG, the industry standard for accessible design) set minimum contrast ratios between text and its background (roughly 4.5:1 for normal body text, 3:1 for large text and UI components like icons or input borders). A color pairing that looks fine to someone with typical vision can fail this ratio and become unreadable for someone with low vision or color blindness.
• Keyboard flow: some users navigate entirely with the keyboard (Tab, Shift+Tab, Enter, arrow keys) instead of a mouse, either by choice or because a mouse is not usable for them. A design that only works on hover, or a modal that traps focus inside it with no way to Tab back out, breaks this.
• Screen reader issues: a screen reader is software that reads the interface aloud from the underlying code, not from what it looks like on screen. An icon-only button with no accessible label, an image with no alternative text, or content that reads in a scrambled order because of how it is structured in the code, all leave a screen reader user unable to tell what a control does.

When critique like this lands, the response has four steps: reproduce the issue yourself with the same assistive technology or checking tool the reviewer used instead of taking the report on faith; scope the fix to the underlying pattern, since the same broken component is usually reused elsewhere; make the change; then validate with the real assistive technology, not only a visual re-check.

Worked example

A reviewer flagged that a confirmation modal I designed for a delete action was unusable for someone navigating by keyboard and screen reader: focus did not move into the modal when it opened, Tab could escape behind it to the page underneath, and the screen reader announced it only as an unlabeled "dialog" with no indication of what action it was confirming. I first reproduced this myself, tabbing through the flow with a screen reader running, and confirmed the reviewer was right: it was disorienting and easy to trigger the wrong action from. The fix moved focus into the modal on open, trapped Tab correctly within it (looping back to the first focusable element instead of leaking out), returned focus to the triggering button on close, and added a clear accessible label and description so the screen reader announced "Delete this project? This cannot be undone" instead of just "dialog." I validated the fix the same way I reproduced the bug: a full keyboard-only pass and a screen reader pass, plus an automated contrast and labeling checker as a fast backstop, not a replacement for the manual pass. Because this was a shared modal component rather than a one-off screen, the fix propagated to every other modal in the product. The process change: I added a mandatory keyboard-only and screen-reader pass to the design review checklist for any new interactive component, and set up a recurring session where the team tests flows with real assistive technology instead of relying only on an automated linter.

Trade-offs and pitfalls

An automated contrast or accessibility checker is fast and good at catching contrast ratios and missing labels, but it cannot tell you whether a keyboard flow is logical or whether a screen reader announcement actually makes sense in context, so treating an automated pass as sufficient is a common and risky shortcut. Meeting the minimum WCAG ratio is a floor, not evidence the experience is actually good for someone using assistive technology, so pair the automated check with a manual pass. There is a real design trade-off between a highly custom, minimal-looking focus indicator and one that is visible enough to meet contrast requirements; the usual resolution is a custom-styled focus ring that still meets the ratio, not removing it to keep the interface looking clean. The biggest pitfall is fixing only the reported instance instead of the underlying component or pattern, which means the same critique resurfaces somewhere else in the product a few weeks later.

Direct answer

Use a STAR structure (Situation, Task, Action, Result), but because this question is specifically
about a failure to act, the "Action" section should center on what you did NOT do and, honestly,
why you hesitated, followed by a Result that names the concrete cost and a closing Learned section
that describes a specific process change, not just a resolution to behave differently.

STAR skeleton to fill in

• Situation: describe the ambiguous context. What made ownership unclear (no assigned owner,
  a gap between two teams, an assumption that someone else was covering it)?
• Task: what decision or action actually needed to happen, and by when?
• Action (framed as inaction): what you noticed, what you did not do, and the specific reason
  you hesitated. Common honest reasons: assuming another team or person owned it, worrying that
  raising it without full information would look like overreacting, or not having clear authority
  to act and not seeking it out.
• Result: the concrete, ideally quantified consequence of the delay.
• Learned and changed: what the hesitation revealed about a gap in the system (not just in your
  personal courage), and the specific, durable change you made to your process so the same gap
  wouldn't cause the same outcome again, even if the same hesitation impulse showed up.

Worked example instance

Situation: midway through a project, a vendor silently renamed a field in a data contract two
weeks before a hard external launch date. Task: someone needed to notice the change and decide
whether to patch the integration or escalate for a possible delay. Action (inaction): I
noticed the anomaly in a routine data check but assumed the vendor's account manager, or another
team lead who worked more closely with that vendor, would flag it and own the fix; I also worried
that raising it without being fully sure it was a real issue would look like overreacting to a
non-problem. Result: the renamed field silently defaulted to null for nine calendar days
(basis: from the date of the schema change to the date the break became visible to a customer)
before a downstream report broke in front of that customer. We ran an emergency data backfill over
a weekend, and the customer's renewal conversation was pushed back three weeks while we rebuilt
trust. Learned and changed: the real gap wasn't that the vendor did something wrong, it was
that "notice this kind of anomaly and act on it" had no assigned owner in the space between the two
teams, and the default human response to that kind of ambiguity is to assume someone else has it.
I implemented a lightweight schema-diff monitor that pages a specific, named on-call person (not a
team inbox) whenever an upstream data contract changes, and I personally adopted a rule: if
something looks like "someone else's job" and I don't see visible action on it within one business
day, I either claim it myself or explicitly hand it to a named person with a deadline, rather than
silently assuming it's covered.

What separates a strong answer from a mediocre one here

A mediocre answer stays vague ("I should have communicated more"), quietly shifts blame outward
(focusing on what the vendor did wrong rather than the candidate's own hesitation), offers a
"lesson learned" that's just a personal resolution with no system behind it ("I learned to speak
up"), or picks an example where the stakes were low enough that "the outcome suffered" doesn't
really hold up. A strong answer names the actual reason for the hesitation honestly (not "I was
busy," but something closer to the real psychological or organizational cause), quantifies the
cost, and produces a change that would prevent the same failure mode even if the same instinct to
assume someone else has it shows up again, because that's what shows the lesson was structural, not
just a promise to try harder.

Second, shorter example (different discipline): the same shape shows up in a marketing
scenario where nobody explicitly owned verifying that a competitor's advertised price change was
real before a promotional campaign launched around it; the fix wasn't "communicate better," it was
assigning a named owner for competitive-claim verification with a required sign-off before any
campaign referencing a competitor goes live.

Trap to avoid

Don't answer this as "tell me about a time I made a mistake" in general. The question specifically
asks about a failure to take ownership under ambiguity, so the hesitation itself, not just the
error, needs to be the center of the story.

Direct answer
Culture fit asks whether you already share a team's existing norms and behaviors; culture add asks what you would bring that the team does not already have. I would describe myself mostly as a culture add: I share the fundamentals a team needs to trust me (reliability, candor, respect for other people's time), but the useful thing I offer beyond that is a genuinely different working background rather than a mirror of the team that is already there.

Structured elaboration

1. Define both terms precisely before answering for yourself. Culture fit is about alignment on shared behaviors and values: does this person operate the way we already operate. Culture add is about complementary difference: does this person's background, working style, or perspective fill a gap the team doesn't currently have.
2. Explain why the distinction matters, not just define it. A team optimized purely for fit tends toward groupthink: everyone reasons the same way, so blind spots go unchallenged and the same kinds of mistakes recur. A team that only adds without any shared fit becomes uncoordinated: people can't predict each other's reasoning enough to move fast together. The healthy target is fit on a small number of load-bearing behaviors (honesty, follow-through, respect) plus deliberate add on everything else.
3. Give a genuine, specific example of your own add, not a generic trait. Vague claims ("I bring diverse perspectives") are the single most common failure mode here; a strong answer names the concrete gap and the concrete evidence.
4. Anticipate the natural follow-up: how do you know your difference is actually useful, versus just different for its own sake. The answer is to point at a specific decision, disagreement, or piece of feedback that changed because of the difference you brought, not just a credential or background fact.

Worked example
Suppose your last two teams were both product engineering teams building consumer-facing features, and the team you're interviewing for is mostly staffed by engineers with that same background. Your own prior role was on a data-platform team, closer to the systems that feed those consumer features than to the features themselves. A concrete add-story: in a past project, a product team wanted to ship a new recommendation feature quickly; because of your platform background, you asked a question the rest of the team hadn't raised (whether the upstream data pipeline's freshness guarantees actually matched what the feature's UI implied to users), which surfaced a real gap between a 24-hour batch refresh and a UI copy that said "updated just for you." The team fixed the copy and adjusted the refresh cadence before launch rather than after a user complaint. That is a genuine add: a different background produced a question the existing team composition was less likely to ask on its own, and it changed a real outcome.

Trade-offs & pitfalls
The common failure is answering only the definitional half (correctly explaining fit versus add) and then, when asked for a personal example, retreating to generic self-description ("I'm a good communicator", "I care about quality") that any candidate could say and that does not actually demonstrate difference. A second pitfall is overcorrecting into implying you don't fit at all; the strongest answers are explicit that you also share the small set of behaviors every functioning team needs, and that add is about everything on top of that baseline, not a replacement for it.

A reproducible severity and priority framework scores each finding on a few independent axes, multiplies them into one number, and sets a fixed cutoff in advance, so the same finding gets the same score no matter who scores it. That reproducibility, not the specific formula, is what makes it defensible to both designers and engineers.

The axes (score each finding 1 to 5)

• Impact: how much the problem hurts the user or the business if left unfixed. 1 is cosmetic, 5 blocks the primary goal.
• Frequency: how many users actually hit it. 1 is rare (roughly 5 percent or fewer of sessions), 5 is common (most sessions).
• Confidence: how solid the evidence is. 1 is a single participant's offhand comment, 5 is triangulated across multiple sessions plus a corroborating data source like analytics or support tickets.
• Effort: engineering and design cost to fix, pulled from engineering, not guessed by design. 1 is under a day, 5 is a multi-week project.

This is close to a RICE score (Reach, Impact, Confidence, Effort, a common product-prioritization framework), adapted here so "Reach" becomes "Frequency," since you're scoring findings you've already observed rather than forecasting reach for a new feature.

Formula and worked example

Priority = (Impact times Frequency times Confidence) divided by Effort.

Take three of the 20 findings:

• Finding A, primary signup button blends into the background: Impact 4, Frequency 5, Confidence 5 (seen in 8 of 10 sessions plus heatmap data), Effort 1 (a one-line style change). Score = (4 x 5 x 5) / 1 = 100.
• Finding B, failed-payment error message doesn't say what to do next: Impact 5, Frequency 2 (payment failures are roughly 3 percent of checkouts), Confidence 4 (seen in 3 of 10 sessions plus support tickets), Effort 2 (new copy and minor logic). Score = (5 x 2 x 4) / 2 = 20.
• Finding C, settings menu uses a different icon style than the rest of the app: Impact 2, Frequency 3, Confidence 3, Effort 3. Score = (2 x 3 x 3) / 3 = 6.

Fixed thresholds, set before scoring anything

• P0, must-fix this sprint: score 40 or above. Finding A lands here.
• P1, next 1 to 2 sprints: score 15 to 39. Finding B lands here.
• P2, research spike or backlog with a re-check date: score 5 to 14. Finding C lands here.
• P3, monitor only: below 5.

Estimating business impact for the readout
For Finding A, if the signup page sees roughly 50,000 sessions a month and a clearer button conservatively recovers even 2 percentage points of completions, that's 50,000 x 0.02 = 1,000 additional completed signups a month. Frame this explicitly as an estimate built on an assumption, not a guarantee, when you present it.

Presenting to PMs and engineers
A single table: Finding, Score, Bucket, Estimated impact, Effort source, Owner. Add one short paragraph per P0 item explaining the evidence behind it, and state up front when the rubric will be re-run (for example, after the next research round), so it reads as a living process rather than a one-time grade.

Trade-offs and pitfalls
A multiplicative formula can bury a rare-but-catastrophic finding, since a high Effort score divides the total down; always hand-check anything with Impact 5 that lands in P2 or lower before accepting the formula's verdict. Confidence must be tied to actual evidence (session count, corroborating data), not how strongly the researcher feels, or the whole scheme becomes theater dressed up as rigor.

Direct answer

Strong candidates use this question to show they can update their own belief when evidence disagrees with it, not to show off a big win. Pick a real story where you had genuine conviction, the test data actually contradicted it, and you can say exactly what changed your mind and what the after-state measured.

Structured elaboration

STAR stands for Situation, Task, Action, and Result: Situation sets the context, Task is what you were trying to achieve, Action is what you specifically did, and Result is the measurable outcome. For this question, weight Action and Result heavily. The interviewer is really asking three things: how much evidence did you have and was it enough to trust, what did the team give up by reversing course, and did the thing you promised actually move after the change.

Worked example

Situation. I designed a compact summary card for an account dashboard, prioritizing scannability by hiding secondary details behind a "see more" toggle. Going in, I believed it was the stronger layout.

Task. Validate the design before it shipped into the shared component library, since other product teams would reuse the pattern.

Action. I ran a moderated usability test (a facilitator watches and interviews people using the product live) with 8 participants doing a realistic task: find whether there was a pending charge on the account. 6 of the 8 participants never found the pending-charge indicator at all, because it was hidden behind the toggle; among the 2 who did find it, time-to-find averaged about 30 seconds. I ran the older, more exposed layout as a counterbalanced second condition inside the same sessions rather than quoting a remembered number for it, and there 8 of 8 found the charge, averaging roughly 10 seconds. Both of those averages are over successful finds only, and I say so whenever I quote them: a task nobody completes has no completion time, so an unqualified "average time-to-find" silently drops the failures and flatters whichever design failed more. I brought the recordings and the count, 6 of 8 missed it, to the team instead of my impression, and proposed two options: keep the compact layout and add a persistent status indicator outside the toggle, a small change, or revert to the fully expanded layout, a bigger visual cost but zero discoverability risk. I recommended the persistent indicator as the smaller, testable change.

Result. After adding the indicator, a follow-up test with 8 new participants, run under the same moderated protocol and the same task wording, found 7 of 8 could locate the pending charge, averaging about 12 seconds among those 7. The headline I reported was the find rate, 2 of 8 to 7 of 8, not the seconds, and the reason is worth stating because it is the part people get wrong: matching the participant count across rounds is not the same as matching the basis. The 30-second before average is computed over only the 2 people who succeeded, the fastest and luckiest slice of the round, while the 12-second after average is computed over 7 of 8. Read naively, that comparison actually understates the improvement, since the 6 who never found the charge contribute no time to the before number at all. If you want a timing comparison that is genuinely on one basis, either cap every unsuccessful attempt at the task time limit and average over all 8 in both rounds, or report the find rate and quote the timings only for the finders with the denominator attached, which is what I did. The team adopted the indicator into the shared component library.

Trade-offs and pitfalls

• The temptation is to tell this story as "I was wrong, I'm humble," which undersells the actual skill being tested: reading evidence rigorously enough to change a real decision, not admitting fault.
• Be honest about sample size. 6 of 8 is a real, useful signal for a usability problem this consistent, but it is not the same as proof from a large-sample A/B test (an experiment that shows two versions to different groups of real visitors and compares an outcome metric at scale). Say so if asked, rather than inflating a small study into "we proved."
• A design that loses a usability test is not automatically wrong everywhere. Name what you kept from your original idea, such as the compact scannability goal, and what specifically needed a different solution.

I would treat this as a scope and risk exercise.

First, I would separate must-have items from nice-to-have items. Legal requirements are usually non-negotiable, so anything needed for compliance, consent, disclosures, or data handling stays in the first release. Then I would protect the core user value: the smallest version of the feature that still solves the main user problem.

Next, I would review the engineering constraint honestly. If the team can only support a narrow scope this quarter, I would avoid designs that depend on extra screens, complex states, or expensive custom interactions. I would choose the simplest flow that is legal, usable, and shippable.

I would communicate the trade-offs in plain language:

• What ships now and why
• What is deferred and why
• What risk remains because of the constraint
• What we will measure after launch

That conversation is easier if I show a release matrix, because it makes clear that deferring something is not rejecting it. It is sequencing it responsibly.

Overview
High-level mobile sign-up flow covering: Email/Password, Social (Google/Facebook), Invite Link. Focus: entry points, decisions, success states, and two error/recovery paths.

User Flow (ASCII)

Start
|
v
Welcome / Landing Screen
|-- [CTA: Sign up with Email] --> Email Sign-up Flow
| |
| v
| Enter email
| |
| Decision: email exists?
| /
| Yes / \ No
| /
| Offer "Log in" or "Continue to create new" Collect password + profile
| \ /
| \ /
| v v
| Verify email (OTP, one-time passcode, /link) --> Success: Account created -> Onboarding
|
|-- [CTA: Continue with Google / Facebook] --> Social Auth Flow
| |
| v
| OAuth popup
| |
| Decision: OAuth success?
| /
| Yes / \ No <-- Error Path A: Social auth failure
| /
| Account exists? Show error "Auth failed"
| / \ |
| Yes / \ No v
| / \ Recovery: Retry / choose Email / Support
| v v
| Login -> Onboarding Create profile -> Onboarding
|
|-- [Entry via Invite Link] --> Open app with token
|
Decision: token valid?
/
Yes / \ No <-- Error Path B: Expired/invalid invite
/
v v
Prefill invite info Show error "Invite expired"
/ \ |
New user Existing user Recovery: Resend invite / Request access / Sign up manually
| |
v v
Create account / Login -> Onboarding

Success states

• Account created + verified -> Onboarding / Home
• Existing user signs in -> Home

Two error/recovery paths

1. Social auth failure: show clear error + inline retry, fallback CTA "Sign up with Email", and "Contact Support" link. Log failure for analytics.
2. Expired invite: show descriptive message, option to request new invite, copy contact info of inviter, and a fallback to create account manually.

Design notes: keep microcopy friendly, surface next-best actions, preserve entered data across retries, and track metrics (drop-off by path, error rates).

Brief framing

As a UI designer I treat prototypes as tools to validate perceived performance, meaning how users feel about wait time, not precise metrics. I combine lightweight animations, simulated latency, and qualitative testing to surface real usability issues before engineering.

Strategies for prototyping and testing

• Skeleton screens: design varying fidelity skeletons (content shapes, progressive reveal) to test whether users feel faster vs blank spinners.
• Progress indicators: experiment with indeterminate vs determinate bars, micro-interactions, and optimistic UI patterns (showing the successful result right away, before the server has actually confirmed it worked, to reduce perceived wait).
• Simulated latency: introduce configurable delays in prototypes (e.g., Framer, ProtoPie, or Storybook with mock APIs) to test behavior at 100ms/500ms/2s.
• Staged content loading: prototype progressive hydration (headers first, then body) and image placeholders to evaluate perceived continuity.
• Measurement in sessions: combine task-based think-aloud with subjective scales (e.g., perceived wait time, frustration) and observation of abandonment.

Deciding what to prototype

• Prioritize high-impact flows (signup, payment, search) and screens with known latency risk.
• Use analytics and SLAs (service-level agreements, an agreed target for how fast something should load): focus on screens with high load times or high drop-off.
• Prototype behaviors where perception matters: gradual reveal, skeleton vs spinner, optimistic updates, and error states.
• If uncertain, run a quick A/B remote test with 2-3 patterns; pick the one with better task success and lower reported friction.

Outcome focus

Report both behavioral (task success, completion time) and subjective metrics (perceived speed, preference) and iterate with devs to ensure a feasible handoff (CSS skeletons, Lottie, lazy-loading strategies).

Direct answer

The right format and settings depend on what the asset actually is, not one house rule: scalable UI icons should ship as optimized SVG, raster hero images should ship as WebP (lossy for photographic content, lossless where pixel-exactness matters) at multiple responsive widths, with a JPEG or PNG fallback only where a consumer genuinely can't decode it, and Android or iOS app assets should ship as density-scaled rasters (or a platform vector format where supported), following each platform's own naming rules. Each case trades off differently between infinite scalability, photographic fidelity, and platform build requirements.

Structured elaboration

When to prefer SVG versus PNG versus WebP: prefer SVG whenever content is genuinely vector, icons, logos, simple illustrations, line art, and the destination can render it directly. Prefer PNG when true lossless quality is required and either the content isn't vector-friendly, a screenshot or a complex illustration with soft transparency, for example, or the platform's build system requires a raster file regardless of the source, which covers most mobile app icon slots. Prefer WebP as the default web raster for photographic or gradient-heavy content: it has a lossy mode that generally beats JPEG at comparable perceived quality and a lossless mode that supports alpha, so it covers both of PNG's and JPEG's web jobs in one format.

The useful way to frame the PNG-versus-WebP call is not "old versus new," it is two questions. First, does this asset need pixel-exact losslessness? A UI screenshot in documentation, a QR code, a flat-color diagram with hard edges: yes, so PNG or lossless WebP, never lossy, because lossy compression puts visible ringing on hard edges and small text. A photograph or a gradient hero: no, so lossy WebP, where the file-size difference is large enough to matter to page load. Second, can every consumer of this asset actually decode WebP? Browsers are not the only consumer: an email client, an embedded webview in an old native app, or a third-party partner's CMS may not be, and that is what a fallback exists for, not a general nervousness about newness. AVIF compresses smaller again and is worth measuring when image weight dominates page load, against a slower encode and a narrower consumer set. Re-check the support assumption at the time you make the decision rather than carrying forward whichever answer was true when you learned it, since that is the part of this that dates.

Worked example

A hero photo needs to ship on a marketing page and on a native app screen. For the web page: export at three widths, 800, 1200, and 1600 pixels, as lossy WebP, each at a quality setting that keeps banding or artifacts imperceptible at normal viewing size while meaningfully reducing file size versus an uncompressed export, wired into a responsive image set so the browser picks the right width, with a JPEG at the same three widths as the fallback for any consumer that can't decode WebP. For the same hero image reused on an iOS screen: export a single fixed-size PNG at @2x and @3x, not a whole width set, since the app controls its own layout width directly, named hero-banner@2x.png and hero-banner@3x.png. For Android: export into drawable-xhdpi, drawable-xxhdpi, and drawable-xxxhdpi at the corresponding pixel dimensions off the same mdpi baseline, filename hero_banner.png, lowercase throughout.

Trade-offs and pitfalls

Defaulting to PNG for everything because it's the most familiar export choice wastes bandwidth on photographic content that would compress far better as lossy WebP, and needlessly multiplies files for content that's actually vector and could have shipped as one SVG. Applying device-density multipliers to a web hero image, instead of layout-width-based breakpoints, ships images sized for the wrong variable: device pixel density and layout width are different things, and conflating them either wastes bandwidth or under-serves a large viewport. Getting Android's filename rule wrong isn't cosmetic, a hyphen or capital letter in a resource filename fails the build outright, so catching it at export time is far cheaper than catching it in a broken build.