Amazon UI Designer (Mid-Level) Interview Preparation Guide

Direct answer

Use one hierarchical naming pattern across every artifact: Component, then variant axis (visual style, or "tone"), then size, then state, expressed consistently in Figma layer names, in the component's code API (props, not separate component names), and in generated CSS classes. The goal is that the same logical name is recognizable whether you're browsing Figma, reading a prop in code, or reading a class name in devtools.

Structured elaboration

Naming layers

• Figma: Button component with variant properties Tone=Primary/Secondary/Critical, Size=Small/Medium/Large, State=Default/Hover/Disabled, browsable as a single component with a properties panel rather than a flat list of separately-named variants.
• Code: one Button component, variants expressed as typed props (tone, size), never as separate component names (PrimaryButton, SmallButton) which multiply combinatorially and can't be discovered by autocomplete.
• CSS classes: generated from the resolved prop combination, e.g. button--primary--md, kept as an implementation detail engineers rarely author by hand.
• File and folder layout: src/components/Button/{Button.tsx, Button.module.css, Button.stories.tsx}, one folder per component regardless of how many variants it has.

Comparing naming conventions for the CSS layer

For large teams, BEM-style class generation (kept internal to the component, not hand-authored) paired with PascalCase for the component name and typed props for variants gets the benefits of each: PascalCase signals "this is one reusable component," props give type-checked, autocomplete-discoverable variant selection, and BEM classes give predictable, debuggable output in devtools without anyone needing to memorize a class-naming scheme.

Worked example

End-to-end for one variant selection:

• Figma: Button component, properties panel set to Tone: Primary, Size: Medium, State: Default.
• Code: <Button tone="primary" size="md">Save</Button>
• Generated class: button button--primary--md
• File: defined once in src/components/Button/Button.tsx, no separate file per variant.

This is discoverable three ways: a designer searches "Button" in Figma and sees every tone/size via the properties panel instead of hunting through a flat list of pre-baked variants; an engineer typing <Button gets autocomplete on tone and size instead of guessing whether the component is called PrimaryButton or ButtonPrimary; and a class name in devtools (button--primary--md) is traceable back to the exact prop combination that produced it.

Trade-offs & pitfalls

BEM class names get long once a component has three or more variant axes (tone, size, state, and maybe density), the mitigation is generating them programmatically rather than hand-authoring, so verbosity is invisible to anyone but the build tool. The most common failure mode this convention prevents is teams inventing free-text variant names in Figma ("Button v2", "Button (new)") that have no code equivalent, once variants are typed props with a fixed enum, both Figma and code are constrained to the same finite set of valid combinations, and "which version is correct" stops being a question anyone has to ask.

Approach summary
I’d audit the UI decisions that affect first paint, perceived completeness, and handoff complexity—then propose concrete changes engineers can implement.

Key UI decisions I’d review/change

• Critical CSS: extract and inline only “hero + navigation” styles per route; keep inline payload < 14KB. Provide a mapped list of selectors and fallback tokens for theming.
• Hydration timing: prefer progressive hydration — hydrate interactive controls (nav, primary CTA) first, defer non-essential microfrontend widgets. Specify priority flags for each element.
• Server-rendered skeletons/placeholders: design low-contrast skeletons matching final layout to prevent visual jump; include explicit dimensions to avoid CLS.
• Lazy-loaded components: mark non-critical microfrontends lazy; supply LCP-safe placeholders and provide a loading state component from the design system.
• Fonts & icons: use font-display: optional or swap; preload only critical fonts; SVG icons inline for critical chrome.
• Style isolation for microfrontends: recommend CSS containment (scoped classes, CSS modules or shadow DOM) and a shared tokens file to avoid flashes from mismatched styles.
• CDN & cache hints: provide critical asset list for preload/prerender and route-based critical-css variants.

Handoff to engineering (deliverables)

• Critical CSS snippets per route + where to inline
• Priority hydration spec: list of nodes, events, and timeouts
• Skeleton components with exact spacing, colors, and dimensions
• Acceptance tests: no FOUC/FOIC on cold load; CLS < 0.1; Time to Interactive targets
• Notes on progressive enhancement and graceful fallback for JS-disabled cases

These changes balance visual polish with engineering constraints and give clear, testable artifacts for implementation.

Context & goal
I hand off a responsive UI so engineers can implement layouts reliably across mobile, tablet, desktop with minimal guesswork and consistent behavior.

Deliverables I provide

• Design files: Figma prototype with pages for Mobile / Tablet / Desktop, component variants, and annotated flows.
• Design tokens: color, spacing, type, radius, elevation, opacity, motion (exportable as JSON/SCSS/Style Dictionary).
• Breakpoints: explicit table (name, min/max width, target devices). Example: small: 0–599px (mobile), medium: 600–1023px (tablet), large: 1024px+ (desktop).
• Component specs: size/spacing rules, responsive modifiers, CSS properties (flex/grid behaviors), min/max widths, collapse/stack rules, and example markup snippets where helpful.
• Responsive behaviors: prioritization rules (what collapses first), content reflow, breakpoint-driven changes, and interaction differences (hover vs touch).
• Accessibility notes: focus order, keyboard behavior, touch target sizes (≥44px), color contrast ratios, aria roles, and reduced-motion alternatives.
• Assets: optimized SVGs, icon sprite, and export instructions.

Organization

• Single handoff folder: /Design (Figma link + version), /Tokens (JSON/SCSS), /Specs (MD files), /Assets, /Changelog.
• README with quick-start: token import, breakpoints, and implementation checklist.

I also schedule a 30–60min walkthrough and stay available for clarifying questions during implementation.

Approach (brief)
I’d simulate conditional form validation in Figma by combining component states, multiple frames/screens, overlays, and careful naming/organization so reviewers can follow branches.

Workarounds & Techniques

• Component variants / interactive components: create a Form component with variants: Empty, Input Invalid (per-field), Inline Error Shown, Submitting, Success. Use “While pressing” or “On click” interactions to swap variants to mimic state changes.
• Multiple frames for branching logic: make separate frames for “Submit -> validation fail” and “Submit -> success.” Link the form Submit button to different frames to represent outcomes.
• Overlays for inline errors and confirmations: use small overlay panels positioned near fields for tooltips/inline errors; use a centered overlay for success confirmation. Overlays keep the main frame intact and feel modal-like.
• Timed transitions: use “After delay” + smart animate to show the submitting state then transition to result frame, creating realistic flow.

Organization & Naming

• Create a Prototype map: root frame, then two visible branches (Error / Success).
• Use clear layer/component names (Form / FieldName / Error / Variant: Invalid). Group variant sets in a “Components / Forms” page.
• Add a README frame with instructions for reviewers to test the paths.

When to switch tools
Move to Axure, ProtoPie, Framer, or a small React prototype when you need: complex conditional logic, data-driven validation, passable inputs, APIs, stateful variables, or developer handoff with real interaction fidelity. Use Figma for quick validation and stakeholder demos; switch when logic or fidelity exceeds Figma’s scope.

Direct answer

Keep a stalled dependency peer-to-peer as long as direct conversation is still making progress. Escalate when you hit a concrete trigger: a scope change that neither side can unilaterally absorb, genuinely conflicting priorities that only someone with visibility into both roadmaps can arbitrate, or a hard deadline-driven blocker where peer-to-peer conversation has already stalled.

Framework

Default: work it peer-to-peer. Most stalls are under-communication or unclear ownership, and a direct conversation or a short written proposal usually unsticks them without anyone else getting involved.

Concrete triggers to escalate.

• Scope change: the fix now requires work neither team budgeted for, and only a manager can reprioritize that.
• Conflicting priorities: both sides are acting rationally from their own team's goals, and the trade-off needs someone with visibility into both roadmaps to arbitrate.
• Hard blocker with a deadline: a fixed external date is genuinely at risk, and peer-to-peer conversation has already stalled past a reasonable window, for example no movement after two direct attempts over several days.
• Repeated pattern: the same kind of stall keeps recurring with the same team, which means the real issue is the working relationship or process, not this one dependency.

What to bring when you escalate. A short brief: what's blocked, what you've already tried peer-to-peer, the realistic options and their trade-offs, and the specific decision you need.

Worked example (applying the criteria)

Situation: your team's deliverable needs a schema change from another team that they've deprioritized for two weeks despite two direct requests.
Applying the criteria: this isn't just a communication gap, direct conversation was already tried twice with no movement. It's a conflicting-priorities case, the other team's roadmap has no room for this without reprioritizing something else, combined with a hard blocker, a fixed external deadline in three weeks that this schema change sits on the critical path for (meaning if this dependency slips, the final deadline slips by the same amount, unlike a dependency with buffer to absorb delay).
Action: escalated to the shared manager with a one-page brief covering what's blocked, the two peer-to-peer attempts and their outcome, and two options: the other team reprioritizes one sprint of work, or your team ships a temporary workaround with known limitations, along with the deadline risk if neither happens within the week.
Result: the shared manager reprioritized one sprint item, unblocking the schema change with two weeks to spare before the deadline. Both teams also agreed to flag scope-affecting asks earlier next time, so the same dependency doesn't reach this point again.

Trade-offs and pitfalls

• Escalating too early over normal friction burns trust and reads as an inability to work horizontally.
• Escalating too late, repeatedly trying peer-to-peer past the point it's actually working, puts the deadline at real risk and looks like poor judgment in hindsight.
• A vague escalation with no options and no specific ask wastes the leader's time compared with a brief that names the decision needed.

Direct answer

When I get stuck on something unfamiliar, the first move is to turn "I'm stuck" into a precise, testable question: not "why is this broken" but "which of these three things is actually causing it." From there I narrow down by testing pieces in isolation, and I bring someone else in on a clock, not a feeling, so I don't burn days flailing but also don't ask before I've done the cheap, obvious checks myself.

Structured elaboration

• Name the actual blocker. A symptom ("the report is wrong") is not a mechanism ("the join is dropping rows with a null key"). I spend the first few minutes just narrowing the symptom to something specific enough to test.
• Decompose into testable parts. Instead of staring at the whole system, I split it into pieces I can check independently: does the input look right, does step one behave as expected in isolation, does step two. This is basically bisection: cut the unknown space in half each time instead of guessing at the whole thing.
• Order of sources, cheapest and most verifiable first. Documentation and existing working examples first (they're free and don't cost anyone else time), then searching for others who hit the same thing, then a specific person, in roughly that order, because each step up costs more of someone else's time and I want to have exhausted the cheap checks first.
• Set a time-box before I start, not after I'm frustrated. I decide up front roughly how long I'll self-serve before escalating, so the decision to ask for help is made by a clock I set with a clear head, not by how annoyed I am two hours in.
• Validate before trusting the fix. Once something looks fixed, I reproduce the original failure once more to confirm I actually understood the cause, not just made a symptom go away, and I check for side effects on the parts I didn't touch.
• Hand the finding back. I write down what the actual cause was and how I found it, even briefly, so the next person who hits this doesn't have to repeat the same search from zero.

Worked example

I once inherited a background job that was silently dropping about one in ten messages after a queue migration, with no errors in the logs anywhere. I narrowed the symptom first: not "messages are lost," but "messages with a specific field are lost," which I found by sending a batch of controlled test messages and diffing what came out against what went in. That let me bisect the pipeline: I checked the message right after it entered the queue (present, correct), then right after the first processing stage (some already missing), so the fault was isolated to that one stage. I gave myself until end of day to find the mechanism before pulling in the engineer who'd built the original queue setup. About three hours in, I found it: the new queue silently truncated messages over a certain size, and the dropped ten percent were exactly the ones with a longer optional field. I fixed the truncation limit, then deliberately reran the same failing batch to confirm the fix actually worked rather than just assuming it, and wrote a short note in our team's incident log explaining the cause so nobody else would spend three hours rediscovering it.

Trade-offs and pitfalls

The two failure modes on either side of this are trying random fixes without narrowing the problem first (which burns time and rarely teaches you anything), and asking for help too early, before doing the cheap checks yourself, which both wastes someone else's time and doesn't build your own ability to do this next time. A fixed time-box protects against both: it stops you from asking too soon out of impatience and from silently struggling too long out of pride. The other real trap is trusting a fix that merely made the symptom disappear once, without reproducing the original failure to confirm you actually understood the cause.

Approach (brief)
I hand off assets so engineers can pick the right file quickly and reliably: correct format for purpose, clear names, density variants, and a single source of truth.

File formats & when to use them

• SVG: icons, logos, simple illustrations — scalable, editable, small. Provide optimized SVGs (clean IDs, no inline styles).
• PNG: complex raster with transparency or when SVG not supported (legacy). Export at @1x/@2x/@3x.
• WebP: production raster for web to save size; provide WebP and fallbacks if needed.

Naming conventions

• component-name.variant.state.size.format
• Examples: icon-search.filled.active.24.svg ; avatar.user.small@2x.png ; hero-background.1920x1080.webp

Density / size variants

• Provide logical base size and multiplies:
  • @1x (24x24), @2x (48x48), @3x (72x72)
• For SVGs include a 24px baseline and optional PNG fallbacks at @1x/@2x.

Where to store / how to surface

• Design system repo (Figma library + exported assets folder) — single source of truth.
• Git repo or CI-backed assets folder: /assets/ui/icons/... with versioning and manifest.
• CDN or S3 for production images; developers get URLs from manifest.
• In Figma, add downloadable exports and a README with naming rules and usage examples.

Extras / handoff tips

• Include a JSON manifest or sprite map listing name, sizes, and URLs.
• Add README with usage examples (CSS, React import).
• Run an audit/cleanup periodically so engineers always pull current files.

Direct answer
A decision genuinely reflects a stated value, rather than merely being compatible with it, when the value actually changed what you chose to do, not just how you described it afterward. The strongest answers make that causal link explicit: what you would have done differently if the value hadn't been a factor.

Structured elaboration

• Situation and task: the decision point, described briefly.
• The counterfactual test: name what the default, easier choice would have been, and what specifically made you choose differently.
• Action: what you actually did, including who you had to convince or coordinate with.
• Result: the outcome, and ideally a signal that the choice was validated rather than merely feeling principled at the time.

Worked example
Faced with a choice between shipping a quick, directionally useful analysis in time for a decision meeting, or spending an additional two weeks on a more rigorous version, the default and professionally "safer" choice would have been to wait for rigor. Choosing to ship the quicker, clearly caveated version instead, because the business decision had a hard deadline and a rigorous-but-late analysis would have been useless, shows a genuine trade-off rather than a reflexive one. The decision was validated when the more rigorous follow-up analysis, completed afterward, confirmed the same direction, meaning the faster call hadn't cost the business a wrong decision.

Trade-offs and pitfalls
A story where the value and the easy choice happen to be the same thing doesn't actually demonstrate anything, since no real trade-off was made; choose a story with genuine tension in it. Naming the value first and building a story to fit it, rather than the reverse, tends to produce something that sounds rationalized rather than genuine; a genuinely reflective answer usually names the counterfactual without being asked. A result stated only as "and it felt right" is weaker than any concrete validation signal, even an imperfect one.

Direct answer. Planning a usability session for participants with vision, motor, or cognitive impairments starts with recruiting real assistive-technology users (not simulating disability with a blindfold on a sighted person, which produces misleading results), building in explicit accessibility accommodations for the session logistics themselves, and running informed consent and task design with enough flexibility that the session measures the product, not the participant's unfamiliarity with an unfamiliar test environment.

Recruitment criteria. Recruit for a specific, named set of conditions relevant to the flow being tested (e.g. screen reader users, users with limited fine motor control, users with ADHD or dyslexia for a content-heavy flow) rather than a vague "people with disabilities" category, since the needs and relevant findings differ substantially across conditions; recruit through disability-community organizations and specialist panels rather than general user-research panels, which tend to under-represent this population.

Accessibility accommodations for the session itself. Confirm the participant's own assistive technology and settings ahead of time and let them use their own device/software rather than the study's, since an unfamiliar AT setup confounds the results with a novice-user effect; offer flexible session length and built-in breaks, since fatigue affects task performance differently for some conditions; provide materials (consent forms, task instructions) in the participant's preferred accessible format in advance.

Consent and ethics. Consent forms need to be accessible themselves (not a scanned PDF image with no text layer); compensate at a fair rate that accounts for the accommodation logistics often taking longer, and be transparent that findings will be used to improve the product, not evaluate the participant's competence with their own tools.

Task scenarios. Realistic, end-to-end tasks ("find and book this flight") rather than isolated component tests, since real usability friction often shows up in the transitions between screens or components, not within any single one; think-aloud protocol adapted for the participant's communication style, since a strict think-aloud requirement can be a poor fit for some cognitive-accessibility participants.

Trade-offs and pitfalls. The most damaging mistake is substituting a sighted researcher's own simulated-impairment experience (a blindfold, one hand tied behind the back) for genuine participant research; simulated impairment reliably produces both false positives (things a sighted novice struggles with that an experienced AT user doesn't) and false negatives (real friction that only surfaces with someone's actual, practiced workflow).

Direct answer

The second explanation almost never wins by being louder or more detailed than the first. It wins by changing the format, meaning I switch from telling to showing, and by rooting the explanation in a decision the person actually needs to make rather than in the mechanics of the tool itself. To avoid condescension, I treat the first miss as information about my explanation, not about their ability.

Structured elaboration

When a first explanation does not land, I go through a specific adjustment process rather than just repeating myself more slowly:

1. Diagnose what actually did not land, by asking a targeted question rather than re-explaining immediately. Usually the gap is one of three things: the vocabulary I used, the lack of a concrete example, or the fact that I explained the mechanism instead of the decision it enables.
2. Change the format, not just the pace. If the first pass was verbal, the second pass gets a visual or a live walkthrough. If the first pass was abstract, the second pass starts from a specific, real example the person already cares about.
3. Anchor the explanation in a decision they need to make, not in how the underlying system works. People retain "here is what you do when you see X" far better than "here is how X is calculated."
4. Check understanding by having them use it themselves, not by asking if it makes sense. Watching someone operate the thing and narrate their reasoning out loud surfaces exactly where the model in their head diverges from reality.

To avoid condescension, I frame the second attempt as "let me show you a different way to look at this" rather than "let me try explaining this more simply," and I never reference the fact that this is a repeat explanation in front of other people.

Worked example

I owned a dashboard that tracked monthly customer churn, acquisition channel, and cohort value for Product and Customer Success managers, most of whom were not technical. After my first walkthrough, several of them still could not use it to decide which customers to prioritize for retention outreach; they nodded along in the room but did not use it afterward.

For the second attempt, I changed three things. First, storytelling: instead of walking through the chart types, I opened with a real scenario, "we're seeing a spike in churn from one acquisition channel this quarter, here is what that costs us and how we'd catch it," and used the dashboard to answer that story as it unfolded. Second, guided filters: rather than describing the filters, I handed them the dashboard and had each person isolate a cohort and change the date range themselves while I coached, so the tool's behavior stopped being something I described and became something they had just done. Third, annotated visuals: I added in-dashboard annotations next to each chart naming the business question it answers, so the connection between a chart and a decision was visible without me being in the room. Afterward, I gave each person a short realistic scenario and had them talk through, using the dashboard, what they would do, which told me directly whether the explanation had landed rather than relying on their saying it made sense.

Trade-offs and pitfalls

• Switching format on the second attempt costs more preparation time than repeating yourself; it is worth it specifically because a second identical explanation rarely succeeds where the first one failed for the same underlying reason.
• Anchoring purely in decisions can under-explain the tool for a stakeholder who later needs to use it in a situation you did not walk through. If the audience needs durable independence, not just one correct decision, the mechanism has to come back in briefly, just after the decision framing rather than before it.
• The biggest condescension risk is not tone, it is implying the person should have understood the first time. Framing the second pass as offering a different angle, rather than a simpler one, avoids that without softening the actual content.
• Hands-on practice only works if you can tolerate the person making a visible mistake in front of you or others; rushing to correct every misstep undercuts the exact learning-by-doing effect you are relying on.