Junior Product Designer Interview Preparation Guide (FAANG Standards)

Direct answer

Map the happy path from discovery to confirmation as five stages (discover, product, cart, checkout, confirmation), decide at each stage what data must be collected and what can wait, and design an explicit alternate path for every place the happy path can break (no stock, failed payment, invalid address) rather than bolting error handling on afterward. If sketching this live and only the first 30 minutes of an exercise are available, get the happy path and the two or three highest-impact edge cases on the board before touching any visual detail.

Structured elaboration

flowchart LR
    A[Discovery] --> B[Product page]
    B -->|Add to cart| C[Cart review]
    B -->|Out of stock| B1[Restock alert or alternatives]
    C --> D[Checkout: shipping]
    D --> E[Checkout: payment]
    E -->|Success| F[Order review]
    E -->|Failure| E1[Retry or alternate method]
    E1 --> E
    F --> G[Confirmation]

Step by step

• Discovery: search or category browse. Decision: view a product or keep browsing. Data collected is mostly implicit (search terms, filters).
• Product page: shows images, variant options, and stock. Decision: pick a variant and add to cart, or save for later. Edge case: out of stock triggers a restock-notify option or suggested alternatives rather than a dead end.
• Cart review: editable quantities, an optional promo-code field tucked behind a "Have a code?" link (progressive disclosure, so most people are not shown a field they will not use). Decision: continue shopping or proceed.
• Checkout, shipping: address (with autocomplete) and delivery method. Edge case: an invalid address gets inline validation with a suggested correction, not a rejected form.
• Checkout, payment: saved card or a new one; guest checkout offered by default, with account creation offered afterward rather than required upfront. Edge case: a failed payment shows the actual reason, a retry, and an alternate method, without losing anything already entered.
• Confirmation: order number, summary, tracking link. A gentle, non-blocking upsell ("you might also like...") appears here, after the sale, not during it.

Worked example

Applying this to a $45 order: discovery via search for "wireless mouse" leads to a product page showing three color variants, one of which (black) is out of stock, so that variant is shown greyed out with a "notify me" link rather than removed. The customer picks the in-stock silver variant, adds to cart, and at checkout enters an address with a typo in the ZIP code; inline validation catches it and offers the corrected ZIP before submission. Payment on a saved card fails (expired card); the error names the reason and offers "use a different card" without clearing the shipping information already entered. On the retry, a different card succeeds, and the confirmation screen shows the order number plus one related accessory as an optional add, not a blocking upsell screen.

Trade-offs and pitfalls

• Forcing account creation before checkout is one of the most common self-inflicted abandonment points; guest checkout first, account creation as a post-purchase offer, avoids it.
• Hiding the promo-code field helps most people, but only if the affordance ("Have a code?") is visible; a field that is truly invisible just frustrates the minority who has one.
• Payment failure messaging that is vague ("something went wrong") pushes people to abandon rather than retry; naming the reason (declined, expired, insufficient funds) keeps the recovery path credible.

Low-fidelity prototype plan

• Goal: validate discoverability, the saving flow, organization (folders/collections), and retrieval from cart.
• Scope: home/feed, product detail, saved items list, save confirmation, create/choose collection, remove/unsave from the list, move to cart.
• Fidelity and deliverables: clickable wireframes in Figma (grayscale, annotations), task flows, a quick interaction map, 6-8 screens.
• Timebox: 4-6 hours to build and share the prototype link.

Recruitment

• Persona: busy 25-45 year-old value-conscious shoppers who browse for later (a mix of frequent app shoppers and occasional ones). Comfortable with mobile apps.
• Device: iOS and Android smartphones (split 50/50).
• Number of participants: 6-8 (remote moderated), enough to surface most usability issues in an exploratory round.

20-minute remote usability test script

• Intro (2 min): brief the purpose, get consent to record, explain think-aloud, remind them there are no wrong answers.
• Pre-task questions (2 min): last time they saved an item; frequency of saving for later.
• Task 1 (4 min): find a product and save it. Success criteria: participant locates the Save affordance within 30s and confirms it saved (visual feedback).
• Task 2 (4 min): create or add the saved item to a named collection. Success: creates/chooses a collection without help and sees the item grouped.
• Task 3 (4 min): find the saved item and move it to cart/checkout, then remove a different item from the saved list. Success: locates the saved list within 30s, adds the item to cart, and removes the second item without help or an accidental deletion (watch for hesitation about whether a removal can be undone, which is the usual failure here).
• Follow-up (3 min): an end-of-session usability rating plus open feedback on pain points and feature ideas. If you want a benchmarkable number, use the full SUS (System Usability Scale, a standard 10-question survey producing a single 0-100 score) and note that it belongs at the end of the whole session, not after each task; if 10 questions will not fit in 3 minutes, ask a single ease-of-task question straight after each task instead.
• Wrap-up (1 min): thanks and next steps.

Success metrics

• Task completion rate, time-on-task, errors, verbalized confusion, qualitative sentiment.

Tools

• Prototype: Figma (interactive frames).
• Remote sessions: Zoom or Lookback (moderated plus recording).
• Recruitment: UserTesting / Respondent or an internal panel.
• Note-taking/analysis: Otter.ai transcription plus Dovetail for synthesis.

This plan prioritizes quick validation of core flows and yields actionable fixes within one sprint.

Direct answer

Separate the trait from your identity, "I do this," not "I am this kind of person," turn the feedback into one specific, observable behavior to change rather than a vague personality fix, and track the result through what other people start doing differently, not a self-reported feeling.

Structured elaboration

1. Processing the feedback. Interpersonal-style feedback lands harder than technical feedback because it can feel like a judgment of character rather than of output. The reframe that helps is translating it into a specific behavior, "I interrupt people mid-thought in meetings," not "I'm not a good listener," since behaviors are changeable and traits feel fixed and personal.
2. Choosing the concrete change. Pick one observable habit to change, not a general resolution. A rule you can self-check in the moment, "let people finish their sentence before I respond, count one beat of silence first," beats a vague intention to "communicate better."
3. Assessing the result honestly. Interpersonal change is genuinely hard to quantify, so the honest signal is behavioral and relational, not a number: being looped into a discussion earlier than before, a colleague raising a half-formed idea with you again without hesitation, the original feedback-giver mentioning unprompted that they noticed a difference.

Worked example

A skip-level review noted that I tended to jump in with a solution before people finished describing the problem, which read as dismissive even though I didn't mean it that way. I turned that into one concrete habit: in any discussion, let the other person finish their point fully, then pause a beat before responding, even if I already thought I knew the answer. The result wasn't a score, it was that a teammate who'd previously stopped bringing half-formed ideas to me started doing it again, and my manager mentioned in a later one-on-one, unprompted, that meetings with me felt less rushed.

Trade-offs and pitfalls

Reporting a precise, fabricated metric, like "my collaboration score went from 3 to 4.5," for something this qualitative is a red flag to an interviewer, not a strength; interpersonal change is real but rarely cleanly measurable, and claiming false precision undercuts credibility rather than adding to it. Treating the feedback as globally true about your whole personality, rather than true in specific contexts, tends to produce overcorrection, going silent in meetings instead of just pausing. And a change nobody else notices isn't actually demonstrated; the answer needs an external signal, even a small one, not just your own resolve.

Situation
At a previous company I ran a B2C onboarding flow for a fintech app. Installs were growing, but activation, a first deposit within 7 days, had stalled at 12% against a 25% goal.

Task
I was asked to diagnose the gap and recommend changes to improve activation and early retention.

Action
I led a week-long research sprint: 20 customer interviews segmented by experience level, a pass through session recordings, and a funnel analysis. I then facilitated a cross-functional persona and journey mapping workshop with product, design, engineering, ops, and support, and we synthesized three personas: Novice Saver, Occasional Investor, and Power Investor. Rather than just writing up findings, I used the resulting journey maps as the shared reference in the next two roadmap review meetings, so when stakeholders disagreed about what to build next, everyone was arguing from the same evidence on the wall instead of restating personal opinions about "the user." The maps showed a specific break for Novice Saver: they dropped off at a multi-step identity-verification screen, before ever seeing a clear reason to trust the product with their money. I proposed reprioritizing from a list of feature requests toward a simplified, education-first onboarding path for that persona specifically: progressive identity verification (collect only what's needed to unlock a small first deposit, ask for more later), a one-tap micro-deposit, and a short contextual explainer with social proof. We built a prototype and ran a 4-week A/B test, control being the existing flow, variant being the new persona-tailored one.

Result
The variant raised 7-day activation from 12% to 29%, a 17-point absolute gain and a 142% relative increase (17/12). Assuming roughly 10,000 monthly signups feed this flow, that 17-point gap translates into about 1,700 more people making a first deposit each month (10,000 x 0.17). Thirty-day retention specifically among Novice Savers rose from 34% to 40%, an 18% relative lift (6/34). Using an average first-90-day deposit value of $120 per newly activated user, the incremental 1,700 monthly activations modeled out to roughly $204,000 in additional monthly deposit-linked revenue (1,700 x $120), a figure finance later confirmed was directionally consistent with actuals after the full rollout. Leadership used the result to re-prioritize the roadmap, deferring several lower-impact features in favor of persona-driven onboarding and in-app education work.

Learned
Personas and journey maps shift a debate from feature opinions to evidence, especially when the artifact itself, not a secondhand summary, is what's projected in the room during the decision. Getting cross-functional alignment early, before the prototype exists, sped up execution once we had results. And a change targeted narrowly at one dominant persona can produce outsized business impact, but it still needs an experiment to prove it before a full rollout, not just a compelling workshop.

Start with a clear priority map: list the primary KPIs and actions stakeholders must see on desktop/tablet (e.g., revenue trend, top 3 segments, alerts). Use that to drive what stays visible vs collapses.

Grid & layout strategy

• Use a 12-column responsive grid (or the dashboard tool’s flexible container system). On desktop use 12 columns; on tablet collapse to 8 or 6 columns and reflow components.
• Define breakpoints (example): desktop ≥1200px, tablet 768–1199px. At each breakpoint, specify column spans for components (e.g., main chart = 6/12 desktop → 8/12 tablet → full width stacked).
• Use consistent gutters (16–24px) and baseline rhythm for spacing.

Deciding hide / stack / resize

• Hide low-priority or verbose elements (detailed tables, long explanatory text) on smaller screens; replace with a link or expandable panel.
• Stack left-to-right desktop panels vertically on tablet in the order of priority: KPI row first, main trend chart next, supporting charts/tables below.
• Resize visualizations to maintain aspect and readable labels; convert complex multi-series charts to simplified versions (e.g., remove secondary axes or reduce series) on smaller screens.

Maintain readability & touch targets

• Typography: scale down headings modestly but keep body >14px. Use high contrast and limit dense labels; use tooltips or on-tap detail for data points.
• Interactive targets: ensure tappable elements are ≥44–48 CSS pixels; increase padding around filters, buttons, and cards. Replace hover-only interactions with explicit taps.
• Use progressive disclosure: collapsible filters, “more details” modals, or drilldowns to avoid clutter while preserving access to detail.

When to build a separate mobile-optimized dashboard

• If key workflows on mobile differ (e.g., field sales need fast single-metric checks and action buttons) or if the desktop dashboard loses essential functionality when compressed, build a separate mobile-optimized view.
• Also choose separate mobile dashboard if performance/complexity (many queries, heavy visuals) would degrade on mobile devices.

Tool-specific notes (Tableau/Power BI)

• Use device layouts (Tableau) or phone layouts (Power BI) to tailor for tablet/phone; use floating objects sparingly and test data queries to keep load times fast.

Measure & iterate

• Validate with real users on target devices; track task completion (can they find key KPI in <10s?), and iterate based on feedback and analytics (clicks, drilldowns).

Direct answer

Preserve what the acquired product's users have actually built trust and muscle memory around, their known color, wordmark, and imagery, and align what is mostly invisible to that user base but costly to maintain separately, spacing conventions and generic UI styling. Decide the split element by element by asking: would changing this make an existing loyal user feel like they are suddenly using a different, unfamiliar product? The test is per element, and it overrides any category label you started with.

Structured elaboration

1. Separate identity elements from system elements. Identity elements are what a user consciously recognizes and associates with trust, the primary brand color, the logo or wordmark, a signature illustration or photography style if the product is known for it. System elements are what users absorb unconsciously, grid and spacing, generic UI chrome like buttons and form fields, things most users have never consciously noticed even though they interact with them on every screen.

2. Treat those two categories as a starting hypothesis, not a verdict. Typography is the element that most often crosses the line: for most products the base text face is a system element nobody could name, but for a product known for a distinctive voice it can be the single strongest identity carrier. Run the recognition test on the specific element in front of you and let the evidence overturn the category. The failure mode here is mechanical: filing "typography" under system elements because it usually belongs there, while your own research is telling you this particular typeface is the thing users write reviews about.

3. Default to preserving identity elements, at least through a transition period, and converging system elements onto your existing brand's system. Converging system elements captures most of the engineering and design efficiency gain at the lowest risk to user trust, since users rarely notice or care about spacing conventions.

4. Where identity elements genuinely conflict, for example the acquired product's primary color clashes badly when both products appear side by side in a cross-sell context, look for a narrower compromise before choosing a side. A useful move is to split the element rather than the decision: keep the acquired product's brand color as a deliberate accent layered onto your layout system, rather than either forcing a full color swap or running two fully separate visual languages indefinitely.

5. Build the stakeholder case on evidence, not preference, and build a different case for each side. Bring concrete signals, brand recognition research if it exists, support ticket sentiment after any earlier visual change, side-by-side screenshots of what a converged screen would actually look like. To the acquired team, the argument is that you are protecting the specific elements their users named, and you can point at which ones. To the acquiring team, the argument is cost: show what running two component sets, two type licenses, and two sets of design reviews costs per year, and show that convergence of the system layer captures nearly all of that saving without touching the elements at risk. Both sides get a decision grounded in something they can check.

Worked example

Say the acquiring company's brand is minimalist, cool blue and gray, with a geometric sans typeface. The acquired product's brand is bold, warm orange and navy, with a rounded, friendly custom typeface that its existing users strongly associate with the product, evidenced by its own app store reviews or support feedback mentioning the "friendly" feel by name.

Run the recognition test element by element. The orange, the rounded wordmark, and, on this evidence, the rounded typeface all fail the "users would not notice" assumption: users named the friendly feel unprompted, and the typeface is where that feeling lives. So the typeface is an identity element here, even though typography usually sits on the system side, and converging it wholesale would be the exact mistake this framework exists to prevent.

The split that follows: keep the orange as the product's primary action color and the rounded wordmark on its marketing surfaces. Keep the rounded typeface too, but scope it to where its character actually registers, headlines, empty states, onboarding, and the wordmark, and converge the workhorse text face used for dense body copy, tables, form labels, and transactional screens onto the acquiring company's system. That preserves the recognized character in the moments users describe as friendly while removing two type families from the maintenance burden of every dense screen. Converge the spacing scale, form components, and neutral color ramp completely, since those genuinely were never something users noticed or valued, and running two separate component sets indefinitely doubles ongoing design and engineering cost for no user-facing benefit.

Note what this buys: the identity/system split cut through the middle of typography rather than assigning it to one side, and that is usually where the good answer lives.

Trade-offs and pitfalls

A common wrong turn is treating this as a pure compromise negotiation, splitting elements roughly fifty-fifty, instead of testing which specific elements actually carry recognition value versus which just happen to be different. The subtler version of the same mistake is applying the identity/system categories mechanically, converging an element because of the bucket it usually falls into while your own evidence says this instance carries recognition. Some "distinctive" choices in the acquired product may simply be dated rather than beloved, and fighting to preserve those wastes political capital that could go toward a genuine identity element instead. On the other side, converging identity elements too quickly, right after an acquisition, before trust in the new parent company is established, risks reading to loyal users as "the thing I liked got erased," even when the underlying system-level convergence was the correct call. And scoping a preserved element rather than keeping it everywhere has a real cost of its own: two type families in one product means someone has to own the rule for which is used where, or the split quietly degrades back into inconsistency.

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

An API is a set of rules that lets two pieces of software ask each other for things and get a response back, the same way a restaurant menu lets you ask the kitchen for a specific dish without needing to know how it's cooked. For support, the practical version is: our product and some other company's system talk to each other automatically over the internet, in a fixed, agreed format, and when that conversation fails, it looks like "the app is broken" even though our code and their code may both be working correctly on their own.

Walking through the request/response flow, and what to leave out

• Client asks, server answers. Frame every API call as one system asking a narrow question ("what is this customer's order status?") and the other giving a narrow answer. Don't teach REST verbs or endpoint names to a support audience, they need the shape of the interaction, not the vocabulary.
• Name the four things that can go wrong, because that's what a support rep actually needs on the spot: the question was asked wrong (a bug on our side), the other system refused to answer (their outage, or our access was revoked), the answer came back garbled or incomplete (a partial failure), or the answer took too long and we gave up waiting (a timeout). Mapping a customer's symptom to one of these four buckets is the real skill being taught here, not the word "API" itself.
• Decide what to omit on purpose: authentication and rate limits are real and matter to engineers, but for a support rep they collapse into one sentence, sometimes the connection itself needs permission or is being used too much, and that shows up looking like the same kind of failure as an outage. Don't walk through how tokens work, it adds vocabulary without adding troubleshooting power.
• Check understanding with a real ticket, not a definition. Hand them a recent "the button doesn't do anything" ticket and ask which of the four failure buckets it fits.

Worked example

Say a customer reports our order-status page came back empty. Behind the scenes, when they loaded that page, our app sent a request to our shipping partner's system asking, in effect, "what's the status of order 48213?" Two things can happen: the shipping partner answers with the status and our page displays it, or something breaks in that exchange, their system is down, our request had a typo, or the token proving we're allowed to ask has expired, and our page has nothing to show, so it renders blank instead of an error message. For the support rep, the API is the reason "our website" and "the shipping company's website" can disagree at the exact same moment: they're two separate systems, and this blank page is what it looks like when the conversation between them fails partway through, not when either system is fundamentally broken.

Trade-offs and pitfalls

The waiter analogy earns its keep for the request/response shape, but it breaks down the moment a rep asks "so can I just call them and ask directly?", real APIs are automated, high-volume, and machine-to-machine, there's no waiter to flag down. Say that limit out loud rather than let them assume a human process exists behind it. The bigger pitfall is oversimplifying past the point of being useful: a support rep who can only say "it's an API problem" can't triage a ticket. The four-bucket failure model above is close to the minimum depth that turns the definition into something actionable, cut much further and the explanation stays clear but becomes useless.

Direct answer

For a remote-first startup, Figma is the strongest recommendation of the three: it's fully browser-based with real-time multiplayer editing built into its core from the start, which matters more for a distributed team than for a co-located one, it has the deepest plugin ecosystem and design-system tooling of the three, and it gives engineering a built-in inspection view for handoff with nothing to install locally. Sketch is a credible second choice for a Mac-heavy team already invested in it, but is a materially weaker fit for a genuinely cross-platform distributed team. Adobe XD is not a sound choice for new work today, since Adobe itself has said it is no longer actively investing in the product.

Structured elaboration

Comparing across the named criteria plus two more worth adding explicitly, file performance at scale and prototyping fidelity:

Recommendation: Figma as the primary tool. "Remote-first" specifically makes real-time multiplayer editing and zero-install browser access disproportionately valuable, and its design-system and handoff tooling reduce the number of separate tools a team would otherwise need to stitch together.

Migration and onboarding considerations. Don't treat a migration from Sketch or Adobe XD as a straight file import: existing tools offer import paths for those file formats, but a component built as loosely grouped layers in the old tool typically needs to be rebuilt as a proper component with real variant properties to get the design-system benefits described above; a mechanical import alone just relocates the mess. Migrate by product area rather than all at once, letting one active initiative prove the new file and naming conventions work before the rest of the backlog follows, and keep the old tool's file as the frozen reference of record until the new one is validated on a real release. Onboarding a distributed team is comparatively light: there's no license to install locally, a new hire is added by email invitation to the relevant projects, and the file and permission structure a team already uses for organization applies unchanged; the main onboarding investment is walking new hires through the team's specific naming and page conventions, not the tool's mechanics.

Trade-offs and pitfalls

Recommending Figma doesn't mean every legacy file needs to migrate on day one; a working existing design-system file, for a small and stable team, represents a real switching cost against a real but not always urgent collaboration benefit, so weigh urgency honestly rather than assuming migration is free. A startup also shouldn't choose a tool purely on today's feature comparison without checking each vendor's own stated direction; a product a vendor has said it's no longer investing in is a real business-continuity risk for a young company that can't easily absorb a forced re-migration later.

Direct answer

Prototype the dropdown in Figma as a set of real interaction states (closed, open, item-focused, disabled) with visible focus styling, validate the keyboard flow inside the prototype, then hand it to engineering as semantic HTML with the appropriate ARIA pattern (listbox or menu) plus JS that manages focus and keys. Test at every stage (design review, code review, and accessibility audit) and document the anatomy, states, and interaction matrix in the design system so every team ships the same behavior.

Structured elaboration

Even though this starts as a Figma task, the designer needs to understand these engineering-level details because the ARIA pattern and focus-management strategy decide which visual states actually need to exist: a visible per-item focus indicator only makes sense to prototype if the implementation genuinely moves focus there. The design and implementation choices aren't independent.

Stage 1: Figma prototyping

• Build every state as a distinct frame or variant: closed, opening/open, item hovered, item focused, item selected, disabled.
• Add a visible focus indicator (ring or outline) as its own layer so it is never lost when engineers translate the file.
• Wire an interactive prototype: Enter/Space opens the list, Arrow keys move between items, Esc closes and returns focus to the trigger, Home/End jump to the first/last item.
• Test in this stage: does the prototype's keyboard flow match a real listbox, is contrast sufficient for text and the focus ring (WCAG 1.4.11 for non-text contrast), is the open/close timing not disorienting.

Stage 2: Implementation

• Pick the ARIA pattern deliberately. A single-select dropdown is usually the APG (the W3C ARIA Authoring Practices Guide, the standard reference for which ARIA role and keyboard behavior fits which UI widget) listbox pattern (button with aria-haspopup="listbox" aria-expanded, a role="listbox" popup, role="option" children) rather than role="menu", because a menu implies commands, not value selection.
• Manage focus with one of two supported strategies: roving tabindex (move tabindex="0" to the active option, everything else -1) or a single focusable listbox with aria-activedescendant pointing at the active option's id. Pick one per component and document it, mixing the two breaks screen readers.
• Key handling: Enter/Space toggles open, ArrowDown/ArrowUp move selection and wrap or stop at the ends (decide and document which), Esc closes and restores focus to the trigger, Home/End jump to first/last option, typeahead (typing a letter jumps to the next matching option) is expected by users of native <select>.
• CSS: keep the focus ring visible (never outline: none without a replacement), respect prefers-reduced-motion for the open/close transition, and position the popup so it does not clip off-screen.

Stage 3: Testing per stage

• Design stage: prototype keyboard flow, motion timing, label clarity, contrast.
• Dev/QA stage: real keyboard-only pass, screen reader pass (VoiceOver + NVDA at minimum, since they diverge on aria-activedescendant support in some browsers), touch target size on mobile, prefers-reduced-motion, RTL layout.
• Automated: axe-core (or equivalent) in CI catches missing labels and role mismatches, but it cannot catch broken keyboard flow, that needs a manual or scripted keyboard test.

Design system documentation

• Anatomy diagram plus the exact markup skeleton (trigger + popup + options).
• A full interaction matrix: every key, every state, and the expected result, so a second engineer implementing a variant does not have to re-derive the behavior.
• Token references used (focus ring color/width, spacing, motion duration) rather than hard-coded values.
• A change log so a fix to focus handling in one place is traceable to every consumer.

Worked example

<div class="dropdown">
  <button id="trigger" aria-haspopup="listbox" aria-expanded="false" aria-controls="list1">
    Sort by
  </button>
  <ul id="list1" role="listbox" tabindex="-1" aria-labelledby="trigger" hidden>
    <li role="option" id="opt-newest" tabindex="-1">Newest</li>
    <li role="option" id="opt-price" tabindex="-1">Price</li>
  </ul>
</div>

const trigger = document.getElementById('trigger');
const list = document.getElementById('list1');
let activeIndex = 0;
const options = () => Array.from(list.querySelectorAll('[role="option"]'));

function open() {
  list.hidden = false;
  trigger.setAttribute('aria-expanded', 'true');
  list.focus();
  setActive(0);
}
function close() {
  list.hidden = true;
  trigger.setAttribute('aria-expanded', 'false');
  trigger.focus();
}
function setActive(i) {
  activeIndex = i;
  list.setAttribute('aria-activedescendant', options()[i].id);
}
list.addEventListener('keydown', (e) => {
  const opts = options();
  if (e.key === 'ArrowDown') { setActive(Math.min(activeIndex + 1, opts.length - 1)); e.preventDefault(); }
  if (e.key === 'ArrowUp') { setActive(Math.max(activeIndex - 1, 0)); e.preventDefault(); }
  if (e.key === 'Escape') close();
  if (e.key === 'Enter') close();
});

This is the aria-activedescendant strategy: the listbox itself holds DOM focus and announces the active option via aria-activedescendant, so the screen reader speaks the option without the browser moving real focus between list items.

Trade-offs & pitfalls

Common wrong turns: using role="menu" for a value-picker (menus are for commands, not selection, and screen readers announce them differently), removing the focus outline for visual polish without a documented replacement, testing only with a mouse so keyboard and screen-reader breakage ships unnoticed, and letting the Figma prototype's timing or copy drift from the shipped component because the design system doc was never updated after a code fix.