Amazon UI Designer (Mid-Level) Interview Preparation Guide

Direct answer

Start from the brand's personality (warm and artisanal versus clean and minimal, for example) and turn that into one lighting recipe, one composition approach, and one color grade that gets applied consistently across every shot. Then split the direction into two distinct jobs: hero shots sell a feeling and can take stylistic license, while product-only shots exist so a shopper can compare items side by side, so they need to stay plain, consistent, true to color, and honest about size.

Structured elaboration

• Lighting: pick one recipe tied to the brand's mood (soft diffused window light at a warm color temperature for "artisanal and warm," or even, cool, shadowless light for "clean and modern") and use it on every shot in a shoot, hero and product alike, so the whole page reads as one photographic family.
• Composition: hero shots use environmental framing (a room, a hand interacting with the object) with generous negative space reserved for a headline or call-to-action; product-only shots use a fixed, centered composition (the same angle and amount of empty margin around every item) so a shopper's eye doesn't have to re-adjust from one product tile to the next.
• Staging (the props and setting placed around a product for a shot): hero shots get lifestyle staging, real surfaces, other complementary objects, implied use, to sell context; product shots get minimal or no staging (a plain, neutral background) so nothing competes with the item itself.
• Color treatment: apply the same color grade (a consistent adjustment to white balance, contrast, and saturation) to every image in a shoot so hue and mood match across the page, but hold product-only shots to accurate, true-to-life color since a customer is using that photo to judge the actual item, while hero shots can lean into the grade more heavily for mood.
• Scannability (how quickly someone can skim a page and compare items): comes from consistency, not starkness, the same crop ratio, the same background, and the same amount of margin around every product so a grid of twelve products reads as one system instead of twelve one-off photoshoots.
• Scale: a fixed margin rule makes every item fill the same share of its frame, which is what makes the grid scannable and also means a large item and a small one look identical in size. That is a deliberate trade, not an oversight, so the direction has to say where physical size gets communicated instead. Handle it outside the grid tile rather than by breaking the margin rule.

Worked example

Say the brand's personality is "warm, handmade, unfussy." The recipe: soft window light at roughly a 45 degree angle with a warm-toned reflector card (avoids the flat, cool look of a ring light), color grade with a warm white balance and slightly lifted shadows (blacks read as soft charcoal, not pure black) applied as one saved preset to every photo. Hero shot for the homepage: a hand pouring tea from a ceramic teapot on a sunlit wood table, shot at a 16:9 crop with the left third left empty for a headline and button. Product shot for the same teapot in the catalog grid: same teapot, same warm grade, but now on a plain linen background, centered, cropped to a 1:1 square with a consistent 10% margin on all sides so it sits at the same visual scale as a much smaller item, like a ceramic spoon rest, photographed under the identical rules. A shopper scanning twelve products in a grid sees consistent framing and consistent color, so their eye is comparing the products, not adjusting to twelve different photographic styles.

Now be explicit about the cost of that rule. A 10% margin on all sides means every item, teapot or spoon rest, occupies the same 80% of its frame, so the grid deliberately throws away relative size. That is the right call for the grid, where the job is comparison of style and color at a glance, but it cannot be the only photography the customer sees, or they will misjudge what is arriving. So the shot list adds a required scale shot per SKU on the product detail page: the item photographed with one consistent human reference, a hand or two hands at a fixed distance, under the same lighting and grade, plus the dimensions shown as text next to the image. The reference has to be the same across the catalog for the same reason the margin is: an inconsistent scale cue is worse than none, because the shopper calibrates on it.

Trade-offs and pitfalls

Over-styling hero images so heavily that the product looks different in the hero shot than in the plain product shot creates a mismatch between what sold the customer and what actually arrives, which drives returns and complaints. Size is the second and often larger source of that same mismatch, and it comes from the uniform-fill rule above rather than from styling, which is why the scale shot is a requirement in the shot list rather than a nice-to-have. Mixing lighting temperatures or grades across a shoot (some images warm, some neutral) breaks the sense that the page is one brand. And letting the hero shot's art direction bleed into product-only shots, extra props, tighter crops, non-standard angles, kills the side-by-side scannability that product photography exists to support. The fix isn't caught in editing after the fact; it comes from a documented shot list the photographer follows before the shoot happens, since inconsistent lighting across hundreds of SKUs can't be uniformly corrected in post, and a missing scale shot cannot be created in post at all.

Direct answer

Persuading engineering leads to give up a sprint means speaking in their currency, cost avoided and risk reduced, not just user delight, and showing up with a scoped, already-prioritized ask instead of an open-ended wishlist they have to whittle down themselves.

Structured elaboration

Quantify the return on investment (ROI). Translate the usability problems into business-relevant costs already visible to engineering: support ticket volume, conversion loss, or the rework cost of patching the same issue piecemeal later. Turn an estimated fix into a rough dollar or time-saved figure, and label it clearly as an estimate rather than a guaranteed number.

Bring concrete artifacts. Annotated session recordings or a handful of representative user quotes tied to timestamps, a prioritized (not exhaustive) list of issues with rough story-point estimates (story points are the relative-effort unit many agile teams size work in instead of raw hours, so a single story-point number only means something next to other work sized the same way), and a before-and-after mock so engineering can see the actual scope, not just hear about it.

Address their concerns directly, not defensively. Scope: offer a must, should, and could split so the ask is negotiable rather than all-or-nothing. Risk: propose feature flags or a staged rollout so a fix is cheap to revert if something goes wrong. Technical debt: acknowledge it openly and offer to pair on it or file it as its own ticket, rather than letting it silently expand the scope of the usability fix itself.

Negotiate, don't dictate. Ask engineering to help re-scope down to what actually fits the sprint, rather than presenting a fixed block of work as non-negotiable.

Worked example

Support logged 92 tickets over the last quarter (roughly 7 a week) about not being able to find where to apply a promo code at checkout, and session recordings show about 1 in 6 checkout sessions abandon at that exact step. The proposed fix, relocating and relabeling the promo code field, is estimated at about 3 story points, roughly half a day of development plus quality assurance (QA) testing.

ROI estimate (clearly labeled as an estimate, with every input stated): if roughly 400 checkout sessions a week reach that step, and 1 in 6 abandon there (about 67 abandons a week), recovering even a conservative one-third of those abandons (about 22 orders a week) at a $40 average order value works out to roughly $890 a week, or somewhere around $3,800 to $3,900 a month. That's presented next to the 3 story-point cost so engineering can weigh it directly, not as a promised guarantee.

Addressing engineering's concerns: scope is capped to the single relabeled field as the "must," with a secondary "could" (a full promo-code UI redesign) explicitly deferred to a later sprint. Risk is handled with a feature flag so the change can be reverted in minutes if something breaks. Technical debt in that part of the checkout code is acknowledged openly, with a separate ticket filed rather than folded into this fix's scope.

This same evidence-and-scoping playbook extends to other multi-party standoffs, not just engineering pushback. When engineering flags implementation cost while marketing wants bolder, more aggressive visuals to lift conversion, the same move applies: build a cheap, low-fidelity prototype of the bold version first and test it before committing engineering budget to the expensive version, so the cost-versus-lift argument is resolved with data instead of two competing opinions. When users say they want simpler navigation while stakeholders insist on more visible options for discoverability, a layered or progressive-disclosure navigation design, a simple default view with an expandable "more" section, resolves both camps at once rather than forcing a single winner.

Trade-offs and pitfalls

• Leading with user empathy alone rarely moves an engineering budget conversation; it needs to be paired with a cost or risk framing engineering already tracks.
• An unscoped "give us a full sprint" ask invites a flat no; making the ask negotiable, with a clear must/should/could split, gives engineering room to say yes to part of it.
• Presenting an ROI estimate without labeling its assumptions explicitly undermines credibility with an audience that will, correctly, poke holes in an unlabeled number.
• If the estimate turns out to be wrong after the fix ships, reporting that honestly (rather than quietly dropping the topic) is what makes the NEXT ROI estimate believable.

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.

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

Aim for 44 by 44 CSS pixels for anything a thumb must hit, and treat 24 by 24 CSS pixels as the floor. Both numbers come from WCAG 2.2 (the Web Content Accessibility Guidelines). WCAG sorts its criteria into three conformance levels: A (lowest), AA (the level most legal and procurement requirements ask for) and AAA (highest, the strictest). Success Criterion 2.5.8 (Level AA) says "The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:" a list of exceptions, and 2.5.5 (Level AAA) says "The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:" its own exceptions. A CSS pixel is a layout unit, not a device pixel, so these sizes survive high-density screens and browser zoom.

To keep a dense desktop toolbar usable without redesigning it, leave the markup and the fine-pointer styles alone and add one @media (pointer: coarse) block that enlarges the buttons, plus flex-wrap: wrap on the toolbar (the flexbox setting that lets items drop onto a new row when they no longer fit) so the bigger buttons break onto a second row. Without it a flex row does not overflow: its items shrink to fit the bar, so the buttons end up smaller than 44px. A "fine" pointer is an accurate one such as a mouse; a "coarse" pointer is a finger on a touchscreen; the browser reports which one the primary input device is through the pointer media feature, a CSS condition about the user's device rather than the window size.

Why the size matters

A fingertip is a much blunter pointer than a mouse cursor, so on a small button it is easy to miss or to hit the neighbour. WCAG states the intent of 2.5.8 as "to help ensure targets can be easily activated", with the full sentence continuing to say without accidentally activating an adjacent target. Two things follow:

• Size and spacing trade off. The 2.5.8 text allows undersized targets when they are spaced so that a 24 CSS pixel circle centred on each does not intersect another target. A dense toolbar can therefore pass AA with small buttons only if they are spread out, and enlarging the buttons is the other way to the same goal. Worked example from WCAG's own explanation of the criterion: the circle has a 12px radius, so the centres of two undersized buttons must be at least 24px apart. Two 20px buttons with a 4px gap have centres 20 + 4 = 24px apart, so the circles only touch and the layout passes; with no gap the centres are 20px apart, the circles overlap and it fails. The 28px buttons in the solution below are already above 24px, so they pass without needing that exception.
• The 44px figure is the Level AAA criterion, stricter than the AA one. Treat AA as the minimum to pass and 44px as the working size for primary controls and anything dense.

Which media query: pointer or any-pointer

MDN defines the feature: "The pointer CSS media feature tests whether the user has a pointing device (such as a mouse), and if so, how accurate the primary pointing device is", where coarse means "a pointing device of limited accuracy, such as a finger on a touchscreen". MDN adds: "If you want to test the accuracy of any pointing device, use any-pointer instead." The primary pointing device is the one the system treats as the main input (on a phone, the touchscreen; on a laptop, usually the trackpad).

Decision: key the size change on (pointer: coarse). It changes density, which is a visible cost on a desktop screen, so it should fire when the primary input is a finger. What flips it: if the product has many touch laptops where users switch between mouse and finger, use (any-pointer: coarse) and accept the larger toolbar for mouse users too. A width query such as max-width: 600px is a poor proxy, because a small laptop window is not a touch device and a tablet is wider than 600px.

The solution

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Toolbar</title>
<link rel="stylesheet" href="toolbar.css">
</head>
<body style="margin:0">
<div class="toolbar">
  <button type="button" aria-label="Bold">B</button>
  <button type="button" aria-label="Italic">I</button>
  <button type="button" aria-label="Underline">U</button>
  <button type="button" aria-label="Link">L</button>
  <button type="button" aria-label="Quote">Q</button>
  <button type="button" aria-label="Code">C</button>
  <button type="button" aria-label="List">#</button>
  <button type="button" aria-label="Clear">X</button>
</div>
<script>
  window.clicks = [];
  document.querySelectorAll('.toolbar button').forEach(b => b.addEventListener('click', () => window.clicks.push(b.getAttribute('aria-label'))));
</script>
</body>
</html>

.toolbar {
  display: flex;
  flex-wrap: wrap;            /* lets the row break instead of shrinking the buttons when they grow */
  gap: 4px;
  width: 300px;
  margin: 16px;
  padding: 0;
}
.toolbar button {
  box-sizing: border-box;
  width: 28px;
  height: 28px;
  padding: 0;
  border: 1px solid #667;
  border-radius: 4px;
  background: #eef0f6;
}

/* Primary input is a finger: same markup, bigger boxes. */
@media (pointer: coarse) {
  .toolbar button {
    width: 44px;
    height: 44px;
  }
}

• The desktop rules are untouched: 28px buttons with a 4px gap.
• The coarse block raises width and height to 44px. Because the buttons are real boxes of that size, the whole 44px square is the target and no extra hit-area trick is needed.
• The toolbar is 300px wide. At 44px with 4px gaps, 6 x 44 + 5 x 4 = 284px fits and 7 x 44 + 6 x 4 = 332px does not, so the eight buttons break into rows of 6 and 2. On a fine pointer, 8 x 28 + 7 x 4 = 252px fits in one row.
• Where wrapping would make the toolbar too tall (a 14-button toolbar at 44px wraps to three rows of 6, 6 and 2, as the last line of the output shows), the alternatives are horizontal scrolling or moving the least-used actions into an overflow menu. Those change the markup and behaviour, which is the point at which "no redesign" stops being possible.

Verifying it

The test runs in Chromium, Firefox and WebKit, the three browser engines (the rendering cores that lay out the page), driven by Playwright 1.48.2, a library that scripts real browsers; its WebKit build is Playwright's, not Safari, and it runs headless, meaning without a visible window, so it can measure layout and simulate a tap but cannot tell how a real thumb feels on a real phone. A fine pointer is the default context. A touch context is created with hasTouch: true, in which matchMedia('(pointer: coarse)') is true in all three engines. It asserts the sizes, the row counts, that nothing pokes out of the toolbar, and that a real touch tap 40px right and 20px down from the first button's corner (inside a 44px box, outside a 28px one) activates it. Deleting the coarse rule or the flex-wrap declaration makes the assertions fail; both mutants fail the 44px size assertion, the second because a non-wrapping flex row shrinks its items to fit instead of letting them overflow.

// check.mjs
import { chromium, firefox, webkit } from 'playwright';
import { readFileSync } from 'node:fs';

const css = readFileSync('toolbar.css', 'utf8');
const html = readFileSync('index.html', 'utf8');
const variants = {
  shipped: css,
  noCoarseRule: css.replace(/@media \(pointer: coarse\) \{[\s\S]*\n\}\n/, ''),
  noWrap: css.replace('flex-wrap: wrap;', 'flex-wrap: nowrap;'),
};
const ok = (c, m) => { if (!c) throw new Error('ASSERT FAILED: ' + m); };

async function open(browser, variant, touch) {
  const ctx = await browser.newContext({ viewport: { width: 400, height: 400 }, hasTouch: touch });
  const p = await ctx.newPage();
  await p.route('**/toolbar.css', r => r.fulfill({ contentType: 'text/css', body: variants[variant] }));
  await p.route('**/index.html', r => r.fulfill({ contentType: 'text/html', body: html }));
  await p.goto('http://x.test/index.html');
  return p;
}
const layout = p => p.evaluate(() => {
  const bar = document.querySelector('.toolbar');
  const r = [...bar.querySelectorAll('button')].map(b => b.getBoundingClientRect());
  const rows = {};
  r.forEach(b => { rows[Math.round(b.top)] = (rows[Math.round(b.top)] || 0) + 1; });
  return {
    coarse: matchMedia('(pointer: coarse)').matches,
    size: [r[0].width, r[0].height],
    perRow: Object.values(rows),
    overflowsBar: r.some(b => b.right > bar.getBoundingClientRect().right + 0.5),
    minSide: Math.min(...r.map(b => Math.min(b.width, b.height))),
  };
});

async function fineTest(b) {
  const p = await open(b, 'shipped', false);
  const m = await layout(p);
  ok(!m.coarse && m.size.join() === '28,28' && m.perRow.join() === '8', 'fine pointer keeps the dense 28px single row');
  return m;
}
async function coarseTest(b, variant) {
  const p = await open(b, variant, true);
  const m = await layout(p);
  ok(m.coarse, 'touch context reports pointer: coarse');
  ok(m.minSide >= 44, 'every button is at least 44 by 44');
  ok(!m.overflowsBar, 'no button pokes out of the toolbar');
  ok(m.perRow.join() === '6,2', 'wraps to rows of 6 and 2');
  // a tap 40px right and 20px down from a button's top-left lands inside its 44px box but outside a 28px one
  const first = await p.evaluate(() => { const r = document.querySelector('.toolbar button').getBoundingClientRect(); return { x: r.x, y: r.y }; });
  await p.touchscreen.tap(first.x + 40, first.y + 20);
  ok((await p.evaluate(() => window.clicks)).join() === 'Bold', 'tap near the edge of the 44px button activates it');
  return m;
}

for (const [name, type] of [['chromium', chromium], ['firefox', firefox], ['webkit', webkit]]) {
  const b = await type.launch();
  const f = await fineTest(b);
  const c = await coarseTest(b, 'shipped');
  console.log(name, 'fine:', JSON.stringify({ size: f.size, perRow: f.perRow }), 'coarse:', JSON.stringify({ size: c.size, perRow: c.perRow }));
  const res = {};
  for (const v of ['noCoarseRule', 'noWrap']) { try { await coarseTest(b, v); res[v] = 'STILL PASSES'; } catch (e) { res[v] = 'fails: ' + e.message; } }
  console.log(' without the rule:', JSON.stringify(res));
  // 14 buttons: clone the first button until there are 14, then count buttons per row at 44px
  const p14 = await open(b, 'shipped', true);
  await p14.evaluate(() => { const bar = document.querySelector('.toolbar'); while (bar.children.length < 14) bar.append(bar.firstElementChild.cloneNode(true)); });
  const m14 = await layout(p14);
  ok(m14.perRow.join() === '6,6,2', '14 buttons wrap to rows of 6, 6 and 2');
  console.log(' 14 buttons, coarse pointer, buttons per row:', JSON.stringify(m14.perRow));
  await b.close();
}

Run in the Playwright 1.48.2 container, it prints the same values for all three engines (repeated runs print the same thing):

chromium fine: {"size":[28,28],"perRow":[8]} coarse: {"size":[44,44],"perRow":[6,2]}
 without the rule: {"noCoarseRule":"fails: ASSERT FAILED: every button is at least 44 by 44","noWrap":"fails: ASSERT FAILED: every button is at least 44 by 44"}
 14 buttons, coarse pointer, buttons per row: [6,6,2]
firefox fine: {"size":[28,28],"perRow":[8]} coarse: {"size":[44,44],"perRow":[6,2]}
 without the rule: {"noCoarseRule":"fails: ASSERT FAILED: every button is at least 44 by 44","noWrap":"fails: ASSERT FAILED: every button is at least 44 by 44"}
 14 buttons, coarse pointer, buttons per row: [6,6,2]
webkit fine: {"size":[28,28],"perRow":[8]} coarse: {"size":[44,44],"perRow":[6,2]}
 without the rule: {"noCoarseRule":"fails: ASSERT FAILED: every button is at least 44 by 44","noWrap":"fails: ASSERT FAILED: every button is at least 44 by 44"}
 14 buttons, coarse pointer, buttons per row: [6,6,2]

How to read it: size is the first button's width and height in CSS pixels; perRow lists how many buttons sit on each row, found by grouping the buttons by the rounded top coordinate of their boxes (getBoundingClientRect() returns a box's position and size), so [6,2] means a row of six and a row of two. In layout(), overflowsBar is true if any button's right edge passes the toolbar's right edge and minSide is the smallest side of any button. fineTest opens a normal (mouse-like) page and expects the dense single row; coarseTest opens a touch page and expects the 44px, two-row result plus the tap. without the rule reruns the touch checks against a stylesheet with the coarse block deleted or with flex-wrap switched off, and fails: followed by the assertion message means the checks caught the missing rule (both mutants trip the 44px size assertion first). The last line adds six more buttons (14 in all) and counts rows again.

Complexity and edge cases

The layout is a single flex pass over eight items. Edge cases to handle:

• Hybrid devices (laptops or tablets that have both a touchscreen and a mouse or trackpad): pointer reports only the primary input (see the MDN definition above), so a touch laptop whose primary input is the trackpad keeps the dense toolbar; any-pointer is true if any attached input matches, so switch to it if that matters.
• Labels: the buttons carry aria-label so the accessible name does not depend on the glyph; resizing them does not change it.
• Page height: wrapping makes the toolbar taller on touch, which pushes content below it down; account for that in the surrounding layout.
• Zoom and user font size: the sizes are in CSS pixels, so they track browser zoom. If the buttons are sized in rem instead, they also track the user's default font size.

Running the code

mkdir demo && cd demo
echo '{"type":"module"}' > package.json
npm i playwright@1.48.2 && npx playwright install chromium firefox webkit
# save the three listings above as index.html, toolbar.css and check.mjs, then:
node check.mjs

Direct answer

The coordination mechanism that actually works is a lightweight, mandatory registration step (an experiment registry) paired with automated overlap detection, not a heavyweight approval committee: every team registers an experiment before launch with its affected flows and user segments, a shared feature-flag system (a code-level switch that turns a feature on or off for a subset of users without a new deploy) checks for overlap automatically, and a small governance group only gets involved when a real conflict is flagged, resolving it against pre-agreed priority rules that trace back to company objectives rather than case-by-case politics. Done well, this keeps experiments aligned with company objectives, avoids user confusion from two conflicting changes hitting the same screen, and preserves statistical validity by catching interaction effects before they silently corrupt both results.

Structured elaboration

Tooling.

• Experiment registry: a single source of truth recording owner, hypothesis, primary and guardrail metrics (a guardrail metric is one you are not trying to improve but must not let get worse), affected flows or UI components, target segments, and start/end dates for every live experiment.
• Feature-flag platform, wired to the registry so every flag maps back to a registered experiment, with a kill switch for fast rollback.
• Overlap detection: automated checks that flag when two experiments target overlapping user segments or touch the same component, before launch rather than after a confusing result shows up.

Process.

1. Registration, a set number of business days before launch, including the affected flows and any known interaction risks.
2. Automated review: the registry flags segment or component overlap with any other active experiment.
3. Human review only on a flag: a lightweight weekly sync (design, product, data) resolves real conflicts; if nothing is flagged, no meeting is needed.
4. Post-launch log: outcomes and any discovered interaction effects get written back to the registry so the next overlapping pair has precedent to work from.

Governance for resolving conflicts. Pre-agree the priority order before a conflict happens, for example company OKRs first, then user-safety or legal constraints, then UX coherence, then incremental exposure (shrink the holdout on the lower-priority experiment rather than canceling it outright). Give the governance group authority to require orthogonal assignment (a different hash salt per experiment, so which arm a user lands in for one carries no information about which arm they land in for the other, paired with an analysis that actually reads the overlap cell instead of ignoring it) or a staggered rollout when a real conflict is found, and set a clear escalation path with an automatic kill if a guardrail metric moves past an agreed threshold.

Worked example

Team A tests a new checkout button placement, targeting 50% of traffic. Team B, unaware of Team A's test, independently tests a redesigned cart page that changes the same page's layout, also targeting 50% of traffic. Two very different things can happen from here, and only one of them is a validity problem; telling them apart is most of what the registry is for.

Case 1: the assignments are statistically independent (different hash salts, so which arm a user gets in A tells you nothing about which arm they get in B). The expected overlap, users on the treatment side of both at once, is $0.5 \times 0.5 = 0.25$, so roughly 25% of all traffic sees both changes simultaneously. That overlap on its own does not bias either read: each team is still comparing its treatment against its control over the same mix of the other experiment's arms, so both main effects remain estimable. What it costs is the interaction (the two changes together performing differently than either alone), which gets averaged into both headline numbers instead of being reported, and some power, because the other experiment's effect adds variance to every metric.

Case 2: the assignments are correlated, which looks identical on a dashboard and is the real killer. If both teams bucket users with the same hash of the user id and the same salt, everyone in A's treatment is also in B's treatment, the two changes are perfectly confounded, and neither team can attribute its result to its own change at all. No number inside either experiment reveals this; only something that knows both are live on the same surface does.

That is what the registry buys, and it is why the choice it unlocks is about assignment and analysis together, not about whether to randomize independently: force the two to be orthogonal (independent salts, verified, so case 2 cannot happen) and analyze the overlap as an explicit 2x2 with a "both variants" cell, which turns the hidden interaction from case 1 into something you can read and size; or stagger them so only one runs at a time on the shared surface, which buys a clean single-factor read at the cost of calendar time. Either way the decision is made before launch, rather than discovering the confound (an outside factor that muddles which change actually caused an observed effect) after the fact from a confusing result.

Trade-offs and pitfalls

A registry that requires heavyweight sign-off for every experiment slows delivery enough that teams start quietly bypassing it, which defeats the purpose; the goal is automated detection with human review reserved for actual conflicts, not a gate on every launch. Under-specifying what counts as "overlap" (only flagging identical experiments rather than shared components or segments) misses the interaction effects that matter most. And a single centralized governance board can become a bottleneck at scale; a workable version delegates most decisions to the automated rules and only escalates genuinely ambiguous priority conflicts.

Direct answer

I'd build the component using Auto Layout (Figma's system for making a frame automatically resize, space, and align its children as content changes, instead of every layer being sized and placed by hand) so its size is driven by whatever content actually fills it, rather than a fixed frame sized to look right with the one tidy example I designed with, then deliberately stress-test it against a spread of realistic and adversarial content, empty, minimal, typical, and maximal, instead of only the happy path, so the breakage shows up in the design file rather than in production.

Building for variability

• Sizing: give every layer the right Auto Layout sizing mode for what it is: "hug" for text that should grow or shrink with its content, "fill" for anything that should stretch to its container, "fixed" only where a size is genuinely constant. The component's overall height or width becomes a function of its actual content, not an assumption baked into the frame.
• Text: decide a max-line or truncation rule up front (e.g. a 2-line clamp with an ellipsis) instead of leaving text unconstrained, and deliberately decide what a very short title (one word) should look like too, not just what a very long one does.
• Images: use a fixed-aspect-ratio container with a defined fill/crop behavior, so user-uploaded images of arbitrary source dimensions don't distort the layout or leave visible gaps. Decide and document what "no image at all" looks like as its own state (the layout reclaims that space, or shows a placeholder), rather than treating it as a smaller version of "has an image."
• Live data feed: design three states beyond the happy path explicitly: empty (real empty-state guidance, not a blank frame), sparse (one or two items, where a grid can otherwise look broken or lonely), and overflow (far more items than fit, needing pagination, infinite scroll, or a "show more" affordance you actually design rather than assume the tool or engineering will handle).

Stress-testing method

Don't validate only against your own placeholder copy. Pull or fabricate a genuinely adversarial content set, the longest real title you can find, a small or oddly-cropped real user-uploaded image, an empty feed and an overloaded one, and drop it into the component across every breakpoint and platform frame, checking specifically for text overlap, image distortion, broken row alignment between sibling cards, and inconsistent row heights in a grid. Re-run the same content set per platform, not just per breakpoint width, since comfortable line length and touch-target sizing differ by platform convention even at similar widths.

Worked example

Take a feed card. Content test set: a 1-character title through a genuinely long real headline (~120 characters); images including a square avatar, a wide banner photo, and a "no image" case; feed sizes of zero items, one item, exactly enough to fill one row, and far more than fit. Result of the stress test: the long headline without a clamp pushes that card's height noticeably past its row neighbors, breaking alignment, fixed by adding a 2-line clamp. The wide banner photo inside a container built for square avatars either stretches or leaves visible letterboxing, fixed by standardizing the image container's aspect ratio and fill behavior regardless of the source image's shape. The "no image" case leaves a blank gray box the same size as a populated one, reading as a broken loading state rather than an intentional one, fixed with a component property that removes the image slot and lets the text stack take that space, used only for the genuine "no image" case (a separate, distinct treatment covers "image still loading"). A one-item feed on a grid built for three columns leaves two glaring empty cells, fixed by having the grid collapse to a left-aligned row of only the populated cards instead of reserving ghost slots.

Trade-offs and pitfalls

• Designing purely for the absolute worst case (every field maxed out) makes the typical, common case look padded and awkward; the goal is testing the full range, then choosing defaults, like a 2-line clamp, that degrade gracefully rather than breaking at the extreme or looking wrong in the common case.
• Treating "no image" as just a smaller version of "has an image" instead of its own layout state is the most common source of a card that reads as subtly broken rather than intentionally different.
• Empty and overflow feed states are often left undesigned because they feel like edge cases, but the choice between pagination, infinite scroll, and a "show more" button is a real UX decision. Leaving it undesigned just hands that decision to whoever implements it, with no design intent behind it.
• Stress-testing with genuinely messy content matters because generic filler text is uniform in a way that hides exactly the length-variance problems the test exists to catch.

Direct answer

Match the method to where you are in the process. A rough early prototype needs a moderated session, because you need to probe confusion in real time and understand the intent behind a hesitation. A near-final flow before launch needs a larger, less-guided sample (unmoderated, or in-person only if the interaction demands it), because a moderator's presence changes behavior in ways that matter more once you are checking whether people succeed unaided, not diagnosing why they might struggle.

Structured elaboration

Method versus process stage

Why the shift happens
Early on, the open question is "where and why do people get confused," which needs a human watching and asking follow-ups in the moment. Close to launch, the open question shifts to "will people get through this without help," which a moderator's presence would quietly distort, since people behave differently when someone is coaching or watching closely versus using the product alone.

When in-person specifically earns its extra cost
Reach for in-person over remote moderated only when the interaction itself is hard to observe over a screen share, for example something involving a physical device or an environment that matters to the task. Otherwise remote moderated gets you the same real-time probing at lower cost.

The mechanics of running any one of these methods well (how to structure tasks, avoid leading questions, choose sample size) is a deeper methodology question in its own right; the point at this stage of the process is picking the right method for where you are, not executing it.

Worked example

A settings flow redesign: at the rough, low-fidelity prototype stage, the team runs five or six moderated sessions, because the goal is to see exactly where people pause and ask why, not just whether they eventually finish. Two weeks before launch, testing the same flow now near-final, the team switches to a larger unmoderated round focused on task completion, because the goal has shifted from diagnosing confusion to confirming the flow holds up without anyone coaching the user through it.

Trade-offs and pitfalls

• Using unmoderated testing too early wastes a rough prototype's biggest value (real-time probing) on a method built for scale, not diagnosis.
• Using moderated testing right before launch introduces facilitator effects into a decision that should reflect unaided, real-world use.
• Choosing a method by budget or convenience alone, instead of by what question you are actually answering at that point in the process, is the most common wrong turn here.

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.

Direct answer

Fully annotated high-fidelity mockups spell out every value directly on the artboard; lighter component-based specs describe intent through named design tokens (shared values like a specific spacing or color, referenced by name rather than a raw number) and existing components, letting the code enforce the actual pixel values. Choose the heavy version for one-off, high-stakes, or unfamiliar-team situations; choose the lighter version once a mature design system exists, because it moves faster and stays correct as the system evolves, while heavy mockups tend to go stale the moment the underlying values change.

Structured elaboration

Worked example

The same card component, spec'd two ways.

Heavy mockup: "Padding: 24px top and bottom, 16px left and right. Corner radius 8px. Shadow: 0px horizontal offset, 2px vertical offset, 4px blur, black at 8% opacity." Every number hand-typed on the artboard. Note that the heavy approach only delivers the "unambiguous" column of the table above if every value is genuinely a number: a phrase like "a soft shadow with light blur" on an annotated mockup reintroduces exactly the guessing the heavy approach was chosen to eliminate, while costing all of its maintenance overhead.

Lighter spec: "Padding uses the large spacing token vertically and the medium spacing token horizontally; corners use the medium radius token; the shadow uses the small elevation token." The two padding values have to stay two tokens. Collapsing them into a single "large spacing token for padding" is the most common way a token spec silently loses information the heavy mockup carried, and it is worse than the heavy version, because the engineer implements one uniform padding, it looks deliberate, and nothing in the spec records that the asymmetry was ever intended.

Now suppose the design system's large-spacing token changes value across the whole product, for a slightly denser layout. The token-based spec updates automatically everywhere it's referenced, because the token itself changed. The fully annotated mockup for this one card still shows its original hand-typed number, and nobody knows to revisit it unless someone remembers that specific artboard exists, so it silently drifts out of sync with the rest of the product.

On velocity specifically: for a single, one-off screen the two are close enough that velocity doesn't decide anything. The heavy version of the card above hand-types seven values (two paddings, a radius, and four shadow parameters) where the lighter one looks up four token names, and that gap is seconds of typing, not a difference in how the team works. The heavy approach starts costing more only once there are many components and many updates over time, which is the long-term maintainability axis, not the day-one speed of producing the first spec. Any count quoted in this comparison is worth re-checking against the example it describes, because a tidy symmetric-sounding count flatters the heavy spec's day-one cost and argues the question on the one axis where the two approaches are nearly tied anyway.

Trade-offs and pitfalls

Choosing the lighter approach before a real token system and shared library exist just recreates the ambiguity of having no spec at all. Sticking with the heavy approach forever, even once a design system matures, means the system's real benefit, cheap propagation of change, never actually gets used. And the two aren't mutually exclusive: a mature system can still add a fully annotated spec for the one truly novel, high-stakes screen, like a compliance disclosure flow, while using lightweight token specs everywhere else. The check that makes the lighter approach safe is a lossless-ness test: read the token spec and ask whether every distinction the heavy version would have made, asymmetric padding, a different radius on one corner, a state-specific elevation, still survives as a named token. Wherever it doesn't, the answer is to add the missing token reference, not to fall back to hand-typed numbers, because a token spec that quietly drops a distinction is the one failure mode that neither approach's pros column protects against.