Amazon Senior UI Designer Interview Preparation Guide

Direct answer

A user persona is a composite, research-grounded profile representing a real cluster of users who share goals, behaviors, and pain points. It is not a photo of one real person and not a demographic label; its purpose is to replace "the user" (a mental picture every stakeholder privately fills in differently) with one shared, evidence-backed reference point, so the team designs for how people actually behave rather than for individual assumptions.

Core sections a usable persona includes (and why each earns its place)

Persona versus a simple demographic segment: a concrete example

Two users can share every demographic trait and still need different products. Take two freelance-marketplace users who are both 32, urban, and earning about $70k a year. One lists a single item a month as a side hustle and is highly price sensitive; the other manages 40 active listings full time and needs bulk editing and payout tracking. A demographic segment groups both under "32, urban, $70k" and would push one generic design. Splitting them into two personas, an Occasional Seller and a Power Seller, produces two different feature roadmaps: a simplified one-item flow for the first, bulk tools and analytics for the second.

When to create a persona versus when a segment is enough

Build a full persona when the decision is behavioral or UX-shaped (which flow, what messaging, what to prioritize) and you can gather qualitative evidence to back it. Rely on a plain demographic or firmographic segment when the decision is a coarser business call (which region to launch, which price tier to target) where a categorical label is sufficient and the cost of a full evidence-backed persona is not justified.

Trade-offs and pitfalls

A persona built without evidence is just a demographic segment wearing a fake name and photo, the same trap dressed up to look more human. More personas is not automatically better; most products are served well by two to four primary personas, kept current, rather than ten that nobody can hold in their head.

Direct answer

I would not open with "we should delay". I would make the case in revenue and risk terms, show options each priced in days, recommend the smallest change that protects the revenue date, and ask for a staged rollout with a pre-agreed trigger. If I lose, I commit to the decision, instrument it, and reopen it only on agreed data.

Step 1: make sure the finding is solid

Usability testing means watching real users attempt tasks. Check how many participants failed, on which task, and whether they were blocked or only slowed. Illustrative finding used below: 5 of 8 participants could not find where to enter the promotion code at checkout. Five failures out of eight is a strong signal but a small sample, so confirm with analytics (the funnel drop-off, meaning the share of users who quit at each step of the flow, at that step) or a quick unmoderated test (participants do the task alone, with their screen recorded and no facilitator, so you can add many more of them cheaply).

Step 2: translate it into leadership's currency

Leadership is optimizing for revenue, so express confusion as lost revenue. Illustrative numbers: 10,000 users start the flow each month, baseline completion (today's share of starters who finish) is 70%, and beta data suggests completion could fall to 62% (an estimate to be confirmed, not a measurement).

Why the delay costs money rather than just moving it: the promo runs in a fixed window, so each day the launch slips is a day of promo revenue that does not happen later (illustrative: $48,000 a month, so 7/30 of it for a week). The two costs have different shapes. The delay is paid once ($11,200). The confusion is paid every month until it is fixed ($16,000 a month), so a one-week fix costs less than a single month of confusion and the gap widens each month the problem stays.

Step 3: the one-slide executive framing

One slide with the decision wanted as the title, a 20-second clip next to the number as evidence, three options with days and revenue effect, and a recommendation with a tripwire (a pre-agreed trigger that reverses or pauses the plan).

What the fix in option C is: relabel the small "Have a code?" link as a visible "Promo code" field and place it above the pay button. It changes wording and position only, not payment logic, so it is cheap (illustrative: 2 to 3 days of work), which is why it fits inside the launch date. The 10% of users who get it are a cohort (a group of users followed together), and the other 90% stay on the old layout until the numbers say it is safe to widen.

Recommendation: C. Tripwire: pause the promo placement if completion stays below 65% across the first 300 starters in the 10% cohort, which separates the estimated 62% from the 70% baseline. It flips to B if the 10% cohort breaches that line. Why 300 starters and not three days: 10% of 10,000 monthly starters is about 1,000 a month, roughly 33 a day, so three days is only about 100 starters, where completion is measured to within roughly 4.8 points (standard error), wider than the 3-point gap between 62% and 65%, so a three-day read would fire or stay silent largely by chance. 300 starters (about nine days) cuts that to roughly 2.8 points, which makes it a screen, not a verdict. A firm read of 62% against the 65% line needs about 700 starters (about three weeks; this is a one-sided 95% read, where the 3-point gap equals 1.64 standard errors, and a conventional two-sided 95% read would need about 1,000 starters, roughly a month at 10%), so if the date allows, widen the cohort to 30% to get there in about a week. Assign the cohort at random so the comparison with the other 90% is fair.

If I lose

Commit and ship without sandbagging (quietly half-hearted execution that lets the decision you opposed fail). Put in the instrumentation (the tracking that records which steps users complete, so the result is visible), log the fix in the backlog with an owner and a date, share the data at the agreed checkpoint, and escalate only if the tripwire is hit on data everyone accepted. Do not say "I told you so".

The same method in other versions of this fight

The same move (price the harm in leadership's units, offer a smaller option) carries over, with illustrative numbers:

Pitfalls

• An ultimatum ("it cannot ship") ends the conversation; options keep it going.
• Do not quote an estimated 62% as fact. Label it, then use the staged rollout to measure it.
• Delay is not the only lever. Changing scope, placement or rollout size often protects both goals.

Direct answer. Consistent accessibility across web, iOS, and Android needs a shared set of accessibility requirements defined at the design-system level (not per-platform ad hoc), translated into each platform's specific accessibility API (the web's ARIA, iOS's UIAccessibility/SwiftUI accessibility modifiers, Android's Accessibility API/Compose semantics), with cross-platform testing that verifies the ACTUAL behavior on each platform's real assistive technology rather than assuming parity from shared design intent alone.

Strategies for platform differences. Define the accessibility requirement at the level of user-facing BEHAVIOR ("this control must be operable and announce its state to a screen reader"), not at the level of a specific attribute name, since the concrete implementation differs entirely by platform: in practice this means: on web you set an attribute, on iOS a modifier, on Android a semantics property, three different syntaxes for telling the OS accessibility layer the control's on/off state. Concretely, a toggle's state is aria-checked on web, accessibilityValue/a SwiftUI .accessibilityValue() modifier on iOS, and a Compose Role.Switch semantics property on Android, three different APIs expressing the same underlying requirement.

Component parity. A shared component's design spec should include a per-platform accessibility implementation note (not just a single generic "make it accessible" instruction) since a component that looks identical across platforms can still differ meaningfully in its accessibility implementation if each platform team interprets the requirement independently without a shared spec to work from.

Testing approaches. Test each platform with its own native, most-commonly-used screen reader (VoiceOver for iOS, TalkBack for Android, NVDA or VoiceOver+Safari for web), not just one platform's tool assumed to generalize; a component's accessibility behavior that's correct on web doesn't guarantee correctness on iOS even with a shared design intent, since the underlying accessibility tree and API surface are genuinely different.

Coordinating across platform teams. A shared accessibility requirements document referenced by all three platform teams, plus a cross-platform accessibility champion role (or regular sync) specifically to catch drift where one platform's implementation diverges from the agreed behavior, since platform teams working in parallel without this coordination point tend to converge on visually similar but behaviorally inconsistent implementations.

Trade-offs and pitfalls. Assuming a shared Figma/design spec alone guarantees behavioral parity across platforms is a common and costly mistake; the design spec communicates visual intent, but each platform's ACTUAL accessibility implementation requires platform-specific technical translation and platform-specific testing, since "looks the same" and "behaves the same to a screen reader" are independent claims.

Approach / goal
I define breakpoints and constraints to reflect real device widths, content needs, and interaction changes so prototypes communicate behavior, not every pixel.

How I pick breakpoints

• Start with content-first breakpoints: where layout or hierarchy must change (e.g., nav becomes hamburger, cards stack). Typical targets: desktop (≥1200px), tablet (768–1024px), mobile (≤375–480px). I adjust values based on analytics and target devices.
• Use fluid ranges between breakpoints, not many rigid sizes. Prototype the key representative widths: large desktop, common tablet (portrait), and common mobile (375px).

Constraints & layout rules

• Prefer fluid grids (12-column with percent gutters) and define min/max widths for containers.
• Mark fixed elements (header/footer height, sticky CTA) and scalable elements (images with aspect-ratio).
• Specify reorder rules: e.g., card grid 3→2→1, sidebar content moves below main, priority content stays top.

Which screens to prototype

• Prototype screens showing different layout states: homepage (multi-column), a dense content page (article/list), and a complex component (form/modal) at each breakpoint.

Handoff to engineers

• Provide a spec sheet: breakpoint values, grid columns/gutter/margins, container max-widths, component constraints (min-width, flex behavior), and reorder rules.
• Include annotated prototypes and short videos demonstrating resize behavior, plus CSS-like notes (e.g., display: grid; grid-template-columns: repeat(3, 1fr); at ≤1024px → repeat(2,1fr)).
• Sync in a short walkthrough to clarify edge cases and prioritize fidelity vs. performance.

Direct answer

Find the shared goal underneath the surface disagreement, both sides usually want the launch to succeed, they disagree on what risk is acceptable to get there. Then convert the abstract tension into a concrete, time-boxed trade-off (what ships now versus what's deferred), with clear ownership of whatever risk gets accepted.

Framework

Reframe before negotiating. Name the actual shared objective (a successful launch) instead of letting the conversation stay framed as one function's priority against another's.

Make the trade-off concrete. Lay out a short options list showing what changes at each risk-versus-speed level, and the cost of each option. Where possible, propose a phased release, ship a reduced-risk version now, defer the rest, rather than forcing an all-or-nothing choice.

Assign ownership of the accepted risk. Whoever accepts a shortcut, for example skipping a test cycle or deferring hardening, should be named explicitly, so the decision isn't 'the team decided' with no accountability attached.

Other shapes this same tension takes. It doesn't always surface as engineering-stability-versus-speed. The identical negotiation shows up as design, performance, accessibility, and time-to-market trade-offs, for example a fully accessible, polished interaction versus a simpler version that ships on the marketing date, and as security, network, and product integration-deadline trade-offs, for example a security or network team wanting a longer hardening pass before a product integration ships, against a fixed launch date on the product side. The mechanism doesn't change across these framings: name the shared goal, make the trade-off explicit and time-boxed, and assign ownership of the risk that's accepted.

Worked example

Situation: engineering wanted an additional hardening and testing pass before a release; the business side had a customer commitment tied to a fixed date, eight weeks out.
Action: convened both sides and reframed the disagreement as 'how do we hit the date without an unacceptable stability risk', not engineering against the business. Broke the release into a smaller core scope that could pass full testing within the eight weeks, with the higher-risk pieces deferred to a fast-follow. Named engineering as the owner of the go/no-go call on stability for the core scope, and named the business side as the owner of communicating the phased scope to the customer.
Result: the reduced-risk core shipped on the committed date, and the deferred piece landed two weeks later with no incident. Because the trade-off was explicit and time-boxed rather than a vague 'we'll be a bit more careful', both sides could tell their own stakeholders exactly what was decided and why.

Trade-offs and pitfalls

• Treating this as a one-time negotiation, rather than designing a recurring mechanism such as a standing risk-versus-release framework, means the same fight repeats at every deadline.
• Splitting the difference without being explicit about what's actually being risked satisfies no one and hides the real trade-off from both sides.
• The senior version of this answer describes redesigning the choice so it isn't zero-sum, the phased release, not describing how you convinced the other side to give in.

Direct answer. Start from the capacity: derive what fits, define the one job the MVP (minimum viable product: the smallest product that tests the core idea) must prove, sort features with MoSCoW, and agree the cut order before work starts. Then explain cuts in terms of the goal, not preferences.

Capacity (illustrative: 2 engineers, 6 weeks). 2 x 6 = 12 person-weeks. Keep a 20% buffer (time held back for surprises): 12 x 0.2 = 2.4, leaving 9.6 person-weeks to plan.

MoSCoW (Must, Should, Could, Won't have this time; an approach from rapid application development, a style of building software in short cycles) with estimates, for a community app where people post and follow each other:

Musts total 8.0, plus the Should 1.5 gives 9.5, within 9.6. Coulds (2.0) are not in the committed plan; they only start if we are ahead. Check the Must share against the DSDM (Dynamic Systems Development Method) guideline. MoSCoW was created by Dai Clegg in 1994 for rapid application development and is used heavily in DSDM, whose published guidance is typically no more than 60% Must Have effort, measured against the planned effort for the timeframe (Won't items excluded), with around 20% Could Have effort as contingency. Planned effort here is 8.0 + 1.5 + 2.0 = 11.5 person-weeks, so Musts are 8.0 / 11.5 = 69.6%, Shoulds 13.0% and Coulds 17.4%. That is above the 60% guideline, so this plan is at the risky end: confidence that every Must lands is lower than DSDM recommends. (Against the whole 12 person-weeks the Musts are 67%, and against the 9.6 plannable weeks 83%, but neither is the basis the guideline uses.) The 2.4-week buffer is my own addition, not part of DSDM's rule, and it does not fix the ratio; the fix is to narrow Musts before the build starts, for example a simpler profile (1.0 instead of 1.5) and a chronological feed (1.5 instead of 2.0), which brings Musts to 7.0 of 10.5 planned (66.7%), closer to the guideline though still above it, and to keep the buffer for the surprises that remain.

What to cut first if it slips. Reverse order of value. Because the Coulds are not in the committed plan, the first cut is simply not starting them (notifications, then analytics beyond one launch event) and spending that time on the buffer. If the slip continues, cut comments next, keeping likes only. Musts are never cut; if even they slip, move the date or the launch audience, not quality of safety features like report and block.

Choosing in/out. I use a PR/FAQ (a press release and customer FAQ written as if launched). Write the headline first, for example: "Neighbours can now sign up, post, follow each other, see a feed and stay safe with report and block." If a feature is not needed to write that headline, it is not a Must; direct messages do not appear in it, so they are a Won't. Another way to cut is to serve one segment first. Suppose the app has moderators (volunteers who review reports), power users (who post daily) and casual users (who mostly read). Pick the segment whose need is sharpest, for example moderators, who need report and block to keep a new community safe, and give the others a clear later path.

Explaining cuts. Show the table and the rule: "This is what the first version must prove. Each cut buys the buffer that protects the date." Give the owner of each Won't a date to revisit.

Direct answer

The core move in an incident explanation to a non-technical audience is separating three layers up front: what happened (in plain terms, no root-cause mechanism), what it meant for them (impact, in terms they already track), and what's being done about it, then deliberately leaving out anything that doesn't serve one of those three. Below is an incident where I did that under time pressure, including delivering it live to a mixed engineering-and-business audience.

What to include, what to leave out, and how to decide

• Lead with impact, not sequence. Legal, sales, and executives care about what happened TO THEM first, which customers, how long, what's the exposure, the technical timeline is useful evidence, not the headline.
• Deliberately exclude logs, stack traces, and internal service names; they add authority for an engineering audience and add nothing but confusion for this one. A useful test: if a detail doesn't change what the listener should do next, leave it out.
• Give the cause in one plain sentence with no jargon, something like "a recent configuration change made one of our systems too slow to respond to a partner service in time," rather than either omitting cause entirely (which reads as evasive) or over-explaining the mechanism.
• When delivering this live rather than in a written report, whether it's a hallway update or presenting a postmortem verbally to a room that mixes engineers and business stakeholders, pause after the impact statement for questions before moving to cause. People worried about impact can't absorb a root-cause explanation until that worry is addressed first.

Worked example

Situation: during a high-traffic sales period, our payment service began intermittently failing checkout requests for roughly ninety minutes. Legal, sales leadership, and the executive team needed an explanation quickly.

Task: explain what happened clearly enough for them to act, communicate with affected customers, assess any obligations, decide on immediate next steps, without either alarming them with irrelevant detail or minimizing the impact.

Action: I opened with impact, in the terms they track: which customers were affected, for roughly how long, and that the issue was fully resolved and being watched closely. I gave the cause in one sentence: a recent configuration change made our payment service too slow to respond to our external payment gateway in time, causing some checkout attempts to fail. I described what we did in plain terms (reverted the change, increased how long we wait before giving up on a slow response, added an automatic circuit breaker so a slow dependency can't cascade into a wider outage) and what we were doing next (a deeper review, with a fuller technical writeup available to anyone who wanted it). I left out the specific error codes, service names, and configuration parameter, none of which changed what legal, sales, or the executives needed to do next. I paused for questions right after the impact statement, before moving on, and answered a legal question about customer notification obligations directly instead of routing it back to engineering jargon.

Result: legal and sales left with a clear, accurate picture of exposure and could communicate confidently with affected customers; the executive team approved the follow-up work (the circuit breaker and review) without needing to dig into implementation detail themselves, and a fuller technical postmortem was made available separately for the engineering team that wanted the mechanism-level explanation. I learned that pausing for questions right after the impact statement, before cause, kept people from tuning out a cause explanation they weren't ready to hear yet.

Trade-offs and pitfalls

Leaving out technical detail can read as evasive if you do it silently; I said "I'm not going to walk through the technical internals here, I'm glad to share those separately" so the omission was visible on purpose rather than hidden. The other pitfall is understating severity to keep the room calm, that erodes trust the moment the real scope becomes clear later. State the honest impact even when it's uncomfortable, and let the "what we're doing about it" section carry the reassurance instead of the impact statement itself.

Direct answer
Different companies name the same underlying idea, owning an outcome end to end and beyond your formally assigned scope, under different labels. Recognizing which of a specific company's named principles maps to that idea, and then having a real, specific story ready, is the actual skill being tested.

Structured elaboration

1. Read the company's actual published list and identify the principle whose description centers on end-to-end accountability and going beyond formal scope, rather than assuming it is whichever principle happens to sound closest to the word "ownership."
2. Select a real story where you did something that was, strictly, not your job, or continued past the point where you could have handed it off to someone else.
3. Structure it briefly: what you noticed, why you didn't wait for someone else to take it on, what you actually did through to completion, and the outcome.
4. Include one honest lesson, ideally something you would do differently next time; a story with no self-critique at all tends to read as less genuine.

Worked example
A project's launch depended on a piece of infrastructure owned by a team that had deprioritized it. Rather than escalating and waiting, or quietly working around the gap, the candidate built the missing piece directly, with the owning team's agreement, on a tight timeline, then handed it back afterward with documentation so that team could maintain it going forward, and followed up a month later to confirm it had actually been adopted rather than quietly abandoned. The lesson: doing the initial work wasn't the hard part; making sure ownership genuinely transferred back afterward, rather than quietly staying with the person who had stepped in, was the part that mattered most and the part that was easiest to skip.

Trade-offs and pitfalls
A story where you took something over and never handed it back can read as scope-grabbing rather than ownership; the follow-through and handoff matter as much as the initial action. Mapping too literally from a principle's name, rather than its actual published description, risks picking the wrong principle for a company whose specific wording differs from what the word alone suggests. A story with no genuine lesson or self-critique often reads as rehearsed rather than reflective.

Direct answer

Layer the token source in three tiers, core tokens shared by all five brands, a brand-override layer that only specifies what differs, and a component-override layer for the rare cases where a brand needs to diverge on one specific component rather than a whole token. Run all three tiers through one build pipeline that emits a versioned package per brand, so shared updates propagate everywhere automatically and brand-specific changes stay isolated.

Structured elaboration

flowchart LR
    Core[Core tokens] --> Merge[Brand override layer]
    Merge --> CompOverride[Component override layer]
    CompOverride --> SD[Style Dictionary transform]
    SD --> Web[Web CSS variables]
    SD --> IOS[iOS Swift constants]
    SD --> AND[Android resources]
    Web --> PkgA[npm brand-a package]
    Web --> PkgB[npm brand-b package]

Three tiers

• Core tokens (core.json): spacing scale, grid, and semantic tokens that every brand shares (color.surface.primary, spacing.stack.16). This is the bulk of the token set, most values genuinely don't need to vary by brand.
• Brand override layer (brand-{name}.json): only the diffs, typically the color palette and primary typeface. A brand file with no overrides is empty and simply inherits core.
• Component override layer: for the rare case where a brand needs a specific component to diverge beyond what a token override can express (say, Brand C's button always has a pill radius regardless of the shared radius.md token), an override lives at the component-token level (button.radius for Brand C specifically), not by forking the component's code.

Resolution order
A component always resolves component-override, then brand-override, then core, falling back one tier at a time, so a brand with no button override still gets the correct shared default.

Build and publish

• Style Dictionary (or equivalent) merges the three tiers per brand and emits platform artifacts (Web CSS variables, iOS Swift constants, Android XML resources) for each.
• Each brand publishes as its own versioned npm package (@org/tokens-brand-a), all depending on a shared @org/tokens-core package so a core-level fix (say, a spacing bug affecting all five brands) is a single change that flows to every brand's next release.

Worked example

button.background resolution for two brands:

Brand A's override cascades to button.background automatically because the component references the semantic token, not a hardcoded value, that's the point of the semantic layer: Brand A never had to touch a button-specific token to change its primary color everywhere the semantic token is used.

Trade-offs & pitfalls

Three resolution tiers means tracing a component's final value by eye gets harder as overrides accumulate, without tooling (a "resolve this token for this brand" CLI or Figma plugin) engineers will resort to reading generated CSS output to debug a color, which defeats the point of the abstraction. The most common failure mode at this scale is a brand team patching a component's code directly to fix a visual mismatch instead of adding a token override, that fix works for their build but silently forks the component from the shared library, and the next core update won't reach them. Publishing five separate packages also adds real release coordination overhead versus a single package with a brand prop, that trade-off is worth it here because five independently deployed brands are exactly the case where isolated release cadences (Brand A shipping a fix without waiting on Brand B's QA cycle) matter more than a single unified release.

Situation & goal
As the UI Designer proposing a responsive layout + new CTAs, success = measurable lift in user engagement and business outcomes while maintaining UX quality across devices.

KPIs (primary + secondary)

• Primary: Conversion rate (CTA click → goal completion), Goal completion rate (sign-up, purchase).
• Secondary: CTA click-through rate (CTR), time-to-first-action, bounce rate, task success rate (usability), visual stability metrics (CLS).
• Qualitative: User feedback, usability test task completion, accessibility checks.

Segmentation

• By device: mobile portrait, mobile landscape, tablet, desktop.
• By platform/os: iOS vs Android vs Web.
• By user cohort: new vs returning, traffic source, screen resolution, high vs low network.
• Prioritize mobile-first if analytics show majority mobile traffic.

Experiment design (A/B)

• Two variants: Control (current) vs Treatment (redesign).
• Randomize at user-cookie or user-id level; persist assignment across sessions.
• Run parallel instrumentation for analytics and qualitative micro-surveys.
• Pre-register metrics and analysis plan; guard against peeking (repeatedly checking results early and stopping the test as soon as they look significant, which inflates the false-positive rate) with sequential testing rules, a statistical method designed to let you check results early without that inflation.

Sample size considerations

• Use baseline conversion p and desired minimum detectable effect (MDE) d.
• Approximate two-sample sample-size formula (per variant), since an A/B test compares two groups against each other rather than one group against a fixed target, so it needs both the significance level and the desired power, not significance alone:

n = (Z_alpha/2 + Z_beta)^2 * (p1 * (1 - p1) + p2 * (1 - p2)) / (p1 - p2)^2

• Choose alpha = 0.05 (Z_alpha/2 = 1.96) and power 80% (Z_beta = 0.84). A common mistake is dropping the power term and using only Z_alpha/2, which understates how many users you actually need. Worked instance: baseline conversion p1 = 5% (0.05), target conversion after the redesign p2 = 6% (0.06), a minimum detectable effect (MDE) of 1 percentage point. Plugging in: n = (1.96 + 0.84)^2 * (0.050.95 + 0.060.94) / 0.01^2 = 7.84 * 0.1039 / 0.0001 ≈ 8,146 users per variant. Inflate that number for segmentation and expected variance, and account for attrition. For low-conversion funnels, run longer or increase the MDE so the required sample size stays reachable.

Rollout criteria

• Rollout if: primary KPI lift is statistically significant, secondary metrics non-degrading, no major UX regressions, accessibility passed, and business stakeholders sign-off.
• Iterate if: marginal/no lift but improved qualitative feedback: run follow-up A/B variants (CTA copy, color, placement).
• Roll back if: negative impact on conversion, engagement, or accessibility.

Notes for execution

• Collaborate with PM/Analytics to instrument events; QA visual specs across breakpoints.
• Complement A/B with session replays and moderated usability on the treatment to explain why metrics moved.