Amazon UI Designer Interview Preparation Guide - Entry Level

Direct answer

Three static frames, one per breakpoint, are the easy part. The real content of a responsive spec is the explicit rules for the space between them: min and max sizing, what reflows or stacks and in what order, and which values are fixed versus which scale fluidly. Present that as a rule table and a simple reflow diagram, not three disconnected screenshots.

Structured elaboration

• A breakpoint is a screen-width threshold at which the layout's rules change, for example "below 600px, stack vertically." Reflow is the reordering or restacking of elements that happens as the viewport crosses that threshold, which is a different thing from an element simply resizing.
• Every complex-component spec needs three parts: the discrete layout per breakpoint tier, explicit min and max width and stacking rules at each threshold, and a clear statement of which values scale fluidly between breakpoints versus which snap at an exact pixel value.
• Use shared design tokens for spacing and type so the same names apply at every size and only their assigned value changes per breakpoint, rather than each screen carrying its own numbers.
• The CSS function clamp() picks a value between a minimum and maximum based on viewport width, letting a size scale smoothly instead of only jumping at breakpoints. In a design tool, an Auto Layout style feature (a constraint-based layout, similar to how CSS flexbox works) can make the design file's own resizing behavior act as a live version of this spec.

Worked example

A card-list component across mobile (up to 600px), tablet (601 to 1024px), and desktop (1025px and up):

• Mobile: vertical stack, image full width on top, then metadata, then actions. Card width is 100% of the container minus 16px padding.
• Tablet: two-column grid; actions move under the metadata. Card min-width 280px, max-width 420px.
• Desktop: horizontal row layout, actions right-aligned. Card width uses clamp(280px, 30vw, 420px). At a 1280px viewport, 30vw is 384px, which falls between 280 and 420, so the card renders at exactly 384px; at a 2000px viewport, 30vw would be 600px, but the 420px maximum caps it there instead.
• A universal rule across all three: long titles truncate at two lines with an ellipsis, with the full text available via a tooltip on hover or focus.
• The mobile-to-tablet transition is specified as an exact, testable boundary rather than "around 600px," which would leave every engineer implementing a slightly different threshold. State it the way the tiers above define it: mobile is everything up to and including 600px, so at exactly 600px the layout is still stacked and the two-column layout first applies at 601px, written as @media (min-width: 601px). Spell out both halves, because "it switches at 600px" is ambiguous about which side 600px itself lands on, and that single pixel is exactly what QA will put a device on.
• One further boundary detail worth writing into the spec, since it is where an otherwise-correct implementation still breaks: browsers report fractional viewport widths on zoomed or scaled displays, so a max-width: 600px / min-width: 601px pair leaves 600.5px matching neither rule and rendering unstyled. Either define every tier by its lower bound only (mobile from 0, tablet from 601px, desktop from 1025px, each overriding the one before) or give the upper bounds a fraction, max-width: 600.98px. Pick one and say which, rather than leaving each engineer to discover the gap.

Trade-offs and pitfalls

Fully fluid, clamp()-based scaling reduces the number of explicit rules to maintain but is harder for an engineer to verify by eye against a static frame; document the minimum and maximum boundary values explicitly, not only the formula. The most common pitfall is specifying only the three static frames and leaving the transition between them undefined, which leads different engineers to implement three different guesses; every threshold needs an exact pixel value. A second common pitfall is assuming images and icons "just scale" and leaving their aspect-ratio and cropping behavior unspecified, when it needs the same explicit treatment as text and layout.

Direct answer

The strongest version of this walkthrough is organized around how your understanding of the problem changed at each phase, not a chronological list of deliverables. State the role you actually played (solo, lead, or contributor within a bigger team) up front, since it frames how much of the story is "I decided" versus "we decided."

Structured elaboration

1. Frame the initial brief honestly, including what was wrong or incomplete about it. Most real briefs are not fully formed. Naming what was missing or assumed at the start, and how that got resolved, is more interesting to an interviewer than a brief that was supposedly correct from day one.

2. Show at least one moment where the thinking genuinely changed. "Research surfaced X, so we changed direction on Y" is the core of the story. A walkthrough with no pivot point at all usually means either the project was too simple to be a good example, or the candidate is not being fully honest about how messy real projects are.

3. Be explicit about your role versus the team's. "I designed the onboarding flow" reads very differently depending on whether you owned it solo, led a small team, or contributed one piece of a larger effort. State it plainly rather than letting the pronouns imply more ownership than there was.

4. Name one trade-off you would still defend today. This is the hardest and most senior part of the question. It should be a real trade-off (something was deliberately not built, or built more simply, in exchange for something else) with the reasoning for why it was the right call, not a humble-brag disguised as a trade-off.

Worked example

Story skeleton: a mobile onboarding flow for a fintech app was losing users partway through signup. The initial brief was "make onboarding feel less like a form," which was vague enough to be a starting point but not a plan. Early research (a handful of user interviews plus a look at where the funnel dropped off) reframed the actual problem: users were not confused by the form fields, they were losing trust at the identity-verification step specifically, which the original brief had not called out. That reframing changed the whole approach, from "redesign the visuals" to "redesign trust signals and explanation at one specific step." As sole owner of the UI work within a small cross-functional team (a PM and two engineers), the designer ran low-fidelity tests on two verification-flow variants, picked the one that tested better for comprehension, and worked with engineering on a phased build that shipped the verification-step fix first and deferred a broader visual refresh to a later release. The trade-off still defended: shipping the narrower, trust-focused fix first instead of the full visual redesign, on the reasoning that the drop-off was concentrated at one step and a full redesign would have taken longer to ship any of it.

Trade-offs and pitfalls

A common weak pattern is a story where nothing about the initial understanding of the problem changes, which usually signals either a shallow project or a shallow retelling of a deeper one. Another is claiming full ownership of a team effort, which tends to unravel under a single follow-up question about who else was involved. The trade-off section is where candidates most often default to something safe ("I'd add more polish if I had time") instead of a real, still-defensible call; naming one that some people on the team actually disagreed with at the time is a stronger signal than one everyone agreed on immediately.

Direct answer

Without having interviewed them, I can only offer hypotheses, not facts, and I would say so. I would build them from the company's product, its customers' jobs to be done (the outcomes customers hire the product to achieve) and public evidence, name the three or four pains I would expect, and then explain the link to the mission. The goal is to show I start from the customer's problem, then check my guesses in the first conversation.

How I would form the hypotheses before the interview

• Read what the company says it does and for whom (the mission and the target customer).
• Skim the places customers talk honestly: product reviews, support forums and community threads, job postings from customers' side, and competitors' reviews.
• Ask "what is the customer trying to get done, and what gets in the way?" That defines a pain point: a specific obstacle that makes a task slow, risky or frustrating.

Illustration (a made-up company: expense-management software for small businesses, mission "make spending simple and visible")

How I would tie each pain to the company's purpose

A pain is relevant to the mission if solving it moves the customer toward the outcome the company promises. If a pain is real but unrelated to the mission (say, complaints about a tax rule the company cannot influence), I would note it, but I would not prioritize it.

In the interview itself

• Ask for recent specific stories ("walk me through the last time you did month-end"), not opinions about features.
• Listen for severity (how bad), frequency (how often) and current workarounds, which show how much the pain is worth. Questions that draw each out: "What happens if the receipts are late?" (severity); "How many times did that come up last month?" (frequency); "What do you do today instead?" (workaround).
• Treat my hypotheses as something that could be wrong. A pain I did not expect is the most useful result.

Pitfalls

• Presenting guesses as findings.
• Listing solutions ("they want an app") instead of pains.
• Naming generic pains ("it is expensive") that would fit any company and show no research.

Direct answer

Use a STAR structure (Situation, Task, Action, Result), but shape it around five things this question specifically names: the original plan, how you discovered the assumption was wrong, how you revised the approach, how you communicated the change, and what you did afterward to prevent a repeat. A strong answer also shows you chose a revision that tried to protect the delivery commitment rather than defaulting to "we pushed the date," and that your communication included not just the fact of the change but its impact on outcomes and on how future decisions would be made.

STAR skeleton to fill in

• Situation: the plan, and specifically which assumption it was quietly built on.
• Task: what you were responsible for delivering, and by when.
• Action, discovery: what surfaced the assumption was false, and how far into execution you were.
• Action, revision: the alternative you chose, including one option you considered and rejected, and whether you managed to protect the original delivery expectation or had to renegotiate it.
• Communication: who you told, what you told them (not just "the plan changed" but the quantified impact), and what it meant for how they, or you, would make similar calls in the future.
• Result and prevention: the outcome, and the specific, durable process change you made, not just a personal resolution to be more careful.

Worked example instance

Situation: I was building a fraud-screening integration into a checkout flow. The plan assumed the vendor's screening call would return within their documented service level agreement (SLA, a contractual performance guarantee) of 500 milliseconds at the 95th percentile (p95, meaning 95% of calls finish at or under that time), which let us call it synchronously before confirming an order. Task: ship a synchronous fraud check inside a 5-week build, without adding noticeable checkout latency. Discovery: two weeks in, a load test against the vendor's sandbox with 10,000 requests showed a real p95 of 4.2 seconds, 8.4 times the documented SLA (4,200ms divided by 500ms), measured on the same basis as the SLA claim: p95 latency under concurrent load. The synchronous assumption was dead. Revision: rather than slip the ship date, I moved the screening call to run asynchronously after the order was placed, holding the order in a short pending-review state, with an auto-approve fallback under a defined risk threshold if the vendor hadn't responded within 3 seconds, matching the checkout's original latency budget. I considered and rejected simply raising our timeout to 5 seconds and keeping it synchronous, because that would have made every checkout feel slow, not just the small share that actually needed review. Communication: within 24 hours I told the product lead, the risk owner, and engineering: the change affected roughly 3% of orders (our historical flag rate) with up to a 3-second delay to their confirmation instead of zero, and I was explicit about the trade-off it created (a small false-approve risk in exchange for keeping the ship date) and what it meant going forward: our next vendor evaluation would need a load-tested p95 number, not just the vendor's advertised SLA, before we could use it to lock an architecture decision. Result and prevention: we shipped on the original date. I added a load-test-before-build gate to our vendor integration checklist so any assumed external latency or throughput number gets independently verified under realistic load before it's allowed to anchor a design decision.

What separates a strong answer from a mediocre one here

A mediocre answer blames the vendor or the documentation instead of examining why the assumption went unverified, describes the revision vaguely ("we adjusted the approach") without a concrete alternative, and treats communication as simply informing people after the fact rather than explaining the quantified impact and what it changes about future decisions. A strong answer picks a revision that tries to preserve the delivery commitment where reasonably possible, is explicit about the option it rejected and why, and turns the incident into a specific, checkable process change.

Second, shorter example (different discipline): a program manager planning an in-person conference assumed a venue's listed capacity of 500 was accurate. A walk-through three weeks before the event revealed fire code actually capped it at 350. Rather than move the date, she added a second overflow room with a livestream, told sponsors the exact new capacity split and what it meant for marketing claims within a day, and afterward added an on-site capacity verification step to the vendor-booking checklist before any date is announced publicly.

Trap to avoid

Don't answer this as a generic "time something went wrong" story. The question is about a load-bearing assumption specifically, so be ready to say plainly why the plan wouldn't have made sense without it, and don't let the discovery and revision sections blur into a single vague "we figured it out."

Direct answer

Preference and retention measure different things: preference is what people say they like in an artificial moment, retention is what they actually keep doing over time in the real product. Treat the conflict as evidence you don't yet understand why B retains better, not as one number overruling the other, and go find the missing piece before deciding.

Structured elaboration

Why these two numbers can legitimately disagree

• Prototype preference tests capture an in-the-moment reaction, often to visual appeal or initial ease, from a small, self-selected group in an artificial setting.
• Live retention captures what people actually keep doing, at real scale, once novelty wears off and real stakes are attached to their choices.
• A design can look nicer at first glance and still fail to support the ongoing behavior that keeps someone coming back, or the reverse.

How to reconcile: triangulate before deciding

1. Check what the two sources are actually comparable on, which is not sample size. A 15-person preference test and a live cohort covering 20 percent of your users will never be similar in size and do not need to be; demanding that would throw out the only evidence you have. Three things do have to line up. Population: were the prototype testers drawn from the same segment generating the retention number, or recruited from a pool that skews toward engaged power users. Window: has Design B been live long enough that you are measuring retention rather than a novelty bump, which for a 30-day metric means at least two full cycles past rollout. And sufficiency, asked of each number on its own terms rather than against the other: a 9-to-6 preference split is not enough to support a claim about the population, while a 30-day retention gap across 20 percent of traffic probably is.
2. Look at the qualitative reasons behind the 60 percent preference for Design A. Was it about a first impression, such as visual polish, or something that should also predict ongoing use, such as perceived ease of a core task?
3. Break Design B's retention down by segment. An aggregate number can hide the real story, the same way an overall onboarding completion rate can look healthy only because it averages over a struggling segment, such as one specific device group, that a topline number quietly hides.
4. Run a targeted follow-up: an A/B test, showing each design to a live, randomly split group of real users rather than a moderated sample, that tracks both an early preference proxy and the longer-term retention metric together, so you are not choosing blind between two different time horizons.

Worked example

60 percent of 15 prototype testers, which is 9 to 6, preferred Design A's cleaner initial layout. Say that split out loud before anyone treats it as a finding: two people changing their minds flips it, so it is a lead to investigate, not a result to weigh against live data. Live analytics on Design B, already shipped to 20 percent of users, show a 12 percent higher 30-day retention than the group still on Design A. Before deciding, you segment B's retention by device and platform and find the lift holds across segments, ruling out a hidden pocket, the kind where an aggregate lift looks fine overall but one platform, say Android, is actually retaining worse under Design B, hidden by better numbers everywhere else. You also read the prototype session notes and find the preference for A was driven almost entirely by first-screen visual polish, not by anything related to the tasks that drive repeat use. Conclusion: ship Design B, but pull Design A's stronger first-screen visual treatment into B's onboarding, since the two designs were actually solving different problems, first impression versus sustained use, rather than being strict alternatives.

Trade-offs and pitfalls

• Defaulting to "retention wins because it's real behavior" is usually right but not automatic. Retention differences can come from a segment effect, a rollout artifact, or plain noise, not the design itself.
• Do not discard the preference data just because it lost. It often points to a real, if smaller, problem worth fixing inside the winning design.
• Segmenting a surprising result is worth doing by habit, not only when something looks off. An average can hide a real problem in one group even when the topline number looks fine.

Direct answer

Pick a project that genuinely missed its goal, not a disguised win or a "weakness that's really a strength." Narrate what happened briefly, then spend most of the answer on root-cause analysis and the concrete practice you changed afterward. Interviewers weight the diagnosis and the behavior change far more than the failure itself.

Structured elaboration

Selecting the story

• The miss has to be real and consequential: a target you clearly did not hit, not a near-miss inside an overall win (that's a different story, see the near-miss variant of this question).
• Pick something you had real decision authority over. "Leadership decided X and it failed" isn't your story to own.

Structure

1. Situation/Task: 2-3 sentences, just enough context to understand the stakes.
2. Action: what you actually controlled, not the whole team's work.
3. Result: state the miss plainly, including what it cost (schedule, trust, money).
4. Root cause, as a distinct pass, split into technical, process, and communication causes. Most real failures have more than one.
5. Changed behavior: the specific practice you adopted afterward, and whether it's held up since.

Ownership calibration
Name your specific role and decisions without blaming teammates or "the org." A senior answer identifies systemic causes it can point to concretely, not just personal fault, and it doesn't hide behind the team either.

Worked example

Situation: six-month project to build a real-time analytics dashboard with a strict latency target under 200ms for filtered queries.

Task: I owned the architecture and delivery.

Action: I chose a custom in-memory indexing approach and, under schedule pressure, deferred load testing until late in the build instead of building it in from the start.

Result: under real load the custom index caused GC pauses (the runtime periodically freezing to reclaim memory), and query latency exceeded the 200ms target by several times over. We missed the launch date and shipped a mitigated version a few weeks late.

Root cause:

• Technical: an unproven custom component was carrying a hard non-functional requirement.
• Process: load testing was deferred instead of scheduled in from day one.
• Communication: I didn't flag the performance risk to stakeholders until it had already materialized.

Changed behavior: I now put a load-test gate before any performance-sensitive feature is considered done, and I default to proven, battle-tested storage/indexing components for hard non-functional requirements instead of building custom ones under time pressure.

Trade-offs & pitfalls

• Choosing a "fake failure" that's secretly a win is the most common wrong turn here, and interviewers see through it immediately.
• Stopping at a generic lesson like "I learned to test more" signals you didn't actually diagnose the cause; name the specific practice that changed.
• Scapegoating teammates or "the org" undermines the ownership signal this question is testing for.
• Don't minimize the real cost of the miss (schedule slip, client impact), but don't catastrophize it either; state it plainly and move to what changed.

Direct answer

For a team this size the file structure should map to ownership, not to project chronology: one design-system file that is the single source of truth for shared components, one project (a project is a folder-like container grouping related files) per active product initiative holding that initiative's editable working file, one standing prototypes project holding a prototype file per product area, and one standing research project for artifacts that inform design but are never themselves shipped.

Structured elaboration

Four file buckets, kept deliberately separate:

1. Design system file. One file, published as a shared team library so other files consume components by reference instead of copy-paste. This keeps the file small and fast and means an update to a component propagates everywhere it's used.
2. Product/feature files. One file per active initiative, owned by the designer driving it, living in that initiative's own project. Components inside are local instances pulled from the library, never duplicated originals.
3. Prototype files. Prototypes with heavy interaction wiring live in their own file, one per product area, and those files sit together in a single standing "Prototypes" project rather than inside each product's project. Two reasons for that placement, and they're the reasons this bucket exists at all: a prototype with many linked frames slows the file down for everyone editing it, and testing artifacts churn faster than production designs and need looser edit access than a product project's own permission policy should allow.
4. Research artifacts. Kept in their own standing "Research" project, never mixed into a component file, since they're synthesis material, not production UI, and they need the same loose edit access as prototypes for the same reason.

Naming pattern: apply project, then file, then page naming.

• Projects: one per product area, named "[Product area]", e.g. "Checkout", "Onboarding Flow", plus three standing projects that are not product areas: "Design System", "Prototypes", "Research".
• File: "[Area] - Product" (the working file, in that area's project), "[Area] - Prototypes" (in the Prototypes project), "[Area] - Research" (in the Research project).
• Pages: every page in every file carries a two-digit numeric prefix, so the sort order stays meaningful as pages are added, and "00 Cover" is page one of every file without exception. A product file's pages are "00 Cover", "01 In progress", "02 Ready for dev", "03 Archive". A file with genuinely different content, the design-system file, say, keeps the same prefix rule with names that fit what it holds. What has to hold everywhere is the prefix and the ordering, not one fixed list of page names for every file.

Permissions:

• Design-system file: edit access limited to the one or two people who own it; everyone else has view/library-consumer access only, preventing accidental edits to shared components.
• Product projects: the owning designer and design lead get edit access; product managers get comment access, so they can leave feedback without moving frames or breaking a layout structure.
• Prototypes and Research projects: broader edit access, since anyone running a test or workshop needs to add notes or frames. This is the concrete payoff of giving those two buckets their own projects instead of scattering their files inside product projects: access is granted per project, so one setting covers every area's prototype file, rather than maintaining a hand-made permission exception inside every product project.

Onboarding benefits from this directly: a fixed project structure and page-naming convention means a new hire's first stop, the design-system file's "00 Cover" page, tells them where everything else lives without a message thread explaining it.

Worked example

A workspace holds projects "Design System", "Checkout", "Onboarding Flow", "Prototypes", and "Research". The Design System file has pages "00 Cover", "01 Foundations", "02 Components", "03 Icons", "04 Changelog", is published as a library, and only the system owner and design lead can edit it. The Checkout project holds one file, "Checkout - Product", with pages "00 Cover", "01 In progress", "02 Ready for dev", "03 Archive", owned by the checkout designer, with the PM on comment access. The heavily-wired 40-frame clickable prototype for an upcoming usability test is not in that project: it lives as "Checkout - Prototypes" in the Prototypes project, kept out of the roughly 200-frame production file so it doesn't slow that file down for the rest of the team, and editable by anyone running the test without touching the Checkout project's permissions. Research findings live as "Checkout - Research" in the Research project, linked from the product file's cover page rather than pasted directly in. The library-performance payoff shows up concretely here: because Checkout's product file only holds instances of the shared Button and Card components rather than duplicated originals, the file stays lean even as the flow grows, and a later corner-radius change to Button in the system file updates every instance across every product file automatically.

Trade-offs and pitfalls

Splitting into too many small files creates its own navigation cost; the four-bucket split above is deliberately coarse, not one file per screen. If the library owner becomes a bottleneck, updates stall, so a documented request-and-review process matters more than restricting edit access ever more tightly. Comment-only access can frustrate a PM who genuinely wants to reorganize a flow, so set that expectation up front rather than loosening the permission the first time it's inconvenient. The most common failure mode is mixing exploratory and shippable work on the same page, letting "In progress" bleed into "Ready for dev", which defeats the whole scheme; that discipline has to be enforced by habit and review, not by the folder structure alone. The second most common failure mode is applying the page convention to product files but quietly skipping it in the design-system file, which is the one file every new hire opens first, so a convention that lapses exactly there fails at the moment it was supposed to pay off.

Direct answer

Define one shared visual grammar, the handful of low-level construction rules like stroke width, grid size, and corner treatment, that every product's icons must obey, and let everything above that layer, which icons exist, any product-specific accent, stay product-specific. Consistency should live in how icons are built, not in forcing every product to use identical icons.

Structured elaboration

1. Identify the true shared layer first. Usually three or four rules, stroke weight, corner radius or join style, grid size, and whether filled or outline is the default, are what actually make icons feel like one family even when the icon shapes themselves differ. Audit each product's current icon set specifically against these attributes to see exactly where they have drifted apart.

2. Rebuild each product's icon set against the shared grammar while keeping each product's existing icon vocabulary intact. A notifications bell stays a bell in both products; the fix is redrawing existing icons to the shared construction rules, not replacing them with one generic set that erases what each product already has.

3. Decide deliberately where to draw the line on what stays unique. Functional or utility icons, settings, search, close, back, should converge fully, since users move between the related products and rely on recognition for exactly these. A product's signature or "hero" icons tied to a genuinely unique feature can keep a distinct flourish, as long as they still obey the shared stroke and grid rules underneath.

4. Sequence the rollout deliberately rather than forcing a simultaneous re-icon everywhere. Migrate the highest-traffic, most-shared icons first, navigation and common actions, since that is where cross-product recognition matters most, and let rarely-used or product-specific icons follow in a later phase.

Worked example

Three related products, A, B, and C, each currently have their own settings, search, and notification icons. An audit finds Product A at a 1.5px stroke with sharp corners, Product B at a 2px stroke with fully rounded corners, and Product C mixed between filled and outline with no consistent grid at all. The team converges all three onto one grammar: a 2px stroke (closer to B's heavier weight, since it holds up better at 16px, the smallest size Product C uses in its dense table rows), rounded joins (matching both B and the shared brand's rounded logotype), and a 24px grid. The roughly fifteen shared utility icons, settings, search, close, notification, back, more, get redrawn across all three products first. Each product's five to ten unique feature icons stay in their current style for a later phase.

Trade-offs and pitfalls

Converging too aggressively, making all three products' icon sets fully identical, can erase legitimate product identity and confuse users who rely on visual differences to know which product they are currently in, especially when the products are marketed as related but distinct rather than one unified suite. Converging too little, agreeing only on a vague guideline like "use rounded corners," does not actually fix the drift, since stroke weight and grid are exactly the attributes users perceive as matching or off, even if they could never name them. A common wrong turn is mandating that every team use one shared icon library file before agreeing on the underlying construction rules; a shared file with inconsistent internal rules just relocates the drift instead of fixing it.

Direct answer

Don't try to average everyone's position into a compromise nobody's happy with. Ground the negotiation in the shared outcome, make the trade-offs between options explicit with evidence, and force a real decision (with an owner and a documented rationale) within a fixed timeframe. A compromise sticks when people can see why it was chosen, not just that it split the difference.

Structured elaboration

1. Reframe around outcome, not position. Ask each stakeholder what success looks like for them, not what they want built. Two stakeholders who seem opposed on the "what" often agree on the "why," which is where the real compromise lives.
2. Bring evidence, not opinions. Gather whatever is available and relevant: usage data, cost/effort estimates, prior incidents, qualitative feedback. A room full of opinions negotiates forever; a room with a shared set of facts converges faster.
3. Make trade-offs visible. Lay out 2-3 real options with their costs and benefits side by side, instead of a single proposal to accept or reject. People compromise more easily when they're choosing between concrete alternatives than when they're being asked to give up a specific ask.
4. Use a structured negotiation move. Propose a balanced default option first, then invite each side to request a bounded concession from it, rather than starting from each side's maximal ask and negotiating down. Time-box the discussion so it doesn't drift into re-litigating the same points.
5. Document the decision and name an owner. Write down what was decided, why, who owns it, and when it will be revisited. If the group truly can't converge, escalate with a specific recommendation rather than an open question, so the escalation itself doesn't become another unresolved debate.
6. Build in a review point. Treat the agreement as provisional and testable, not permanent. A short follow-up (after the next milestone, or a fixed number of weeks) to check whether the compromise is actually working keeps people bought in because they know it isn't final and unappealable.

Worked example

Three stakeholders disagree on scope for a feature: one wants the full version shipped now, one wants it deferred a quarter, one wants a stripped-down version shipped immediately. Instead of negotiating "how much scope," the facilitator asks each what outcome they're protecting: the first is protecting a customer commitment, the second is protecting engineering capacity for other work, the third is protecting the team's ability to learn before over-investing. That reframing surfaces a real option none of them had proposed: ship a narrow version that satisfies the customer commitment, explicitly scoped as a first iteration, with the deferred work logged and re-prioritized at the next planning cycle. The decision, the scope boundary, and the re-prioritization date are written down and shared with all three stakeholders.

Trade-offs & pitfalls

• Pitfall: false compromise, where everyone gets a token piece of what they asked for and the result satisfies no one's actual underlying need.
• Pitfall: skipping documentation. An undocumented "agreement" gets re-argued the moment someone's memory of it differs.
• Pitfall: treating consensus as required. Some decisions need a single accountable owner to make the call after input, not unanimous agreement, especially under a deadline.
• Senior differentiator: designing the forcing function (a default option, a timebox, a named decision owner) instead of facilitating an open-ended discussion indefinitely. That's what turns "several people who each want something different" into an actual decision.

Direct answer

The root problem is that there's no agreed-upon naming convention, so fix it by defining one (category first, then semantic intent, consistent case, no raw color words), migrating existing tokens to it with aliases so nothing breaks mid-migration, and enforcing it going forward with a lint rule so it doesn't decay again.

Structured elaboration

Diagnosing the mess

• blue1 names by raw appearance, not intent, if the brand color changes from blue to teal, every consumer of blue1 now has a lying name.
• Color_Brand mixes case style (PascalCase-ish with underscores) inconsistent with the rest of the system, and is too generic, brand color for what, background, text, border?
• spacing-SM mixes kebab-case with an uppercase abbreviation, and "SM" isn't self-explanatory to someone new to the system.

Naming convention

• Structure: <category>-<semantic-intent>-<scale-step>, all lowercase kebab-case for cross-platform portability (uppercase and underscores don't survive some platform transforms cleanly).
• Name by intent, not appearance: color-brand-primary, not blue1, so the name stays true after a rebrand.
• Spell out scale steps consistently: spacing-sm, spacing-md, spacing-lg (lowercase, full word, not SM).

Migration strategy

• Don't rename in place, add the new name as the canonical token and alias the old name to it, so existing consumers keep working while new work adopts the new name.
• Set a deprecation window (e.g. a documented removal date) and a lint warning on any new use of a deprecated name.
• Remove the alias only after usage telemetry (or a code search) shows zero remaining references.

Enforcement

• A lint rule (or a CI check against the token schema) that rejects any new token that doesn't match the naming pattern, this is what prevents the same drift from recurring six months later.

Worked example

Migration mapping table for the tokens in the scenario:

The blue1 / Color_Brand collision is the important part of this exercise: a naming fix can surface that two "different" tokens were actually meant to represent the same design decision, or reveal that they were never meant to be the same value at all. Either way, that's a decision for whoever owns the token source to resolve explicitly, not something the naming convention alone can paper over.

Trade-offs & pitfalls

Renaming without an alias layer breaks every consumer at once, the moment you change a token name is exactly when you can't afford a hard cutover on a live product. The second pitfall is normalizing the name without checking whether two similarly-named tokens (blue1 and Color_Brand) actually hold the same value, silently merging them if they don't will introduce a visual regression that's much harder to trace back to "we cleaned up token names" than a naming inconsistency ever was. Governance (a lint rule, a review step for new tokens) is what keeps the fix from being undone by the next engineer who needs a color in a hurry and doesn't know the convention exists.