Entry-Level Product Designer Interview Preparation Guide - Spotify

Direct answer

The core risk in a mixed remote and in-person briefing is that the two groups silently have different experiences of the same meeting: the in-person half gets body language and side comments the remote half never sees, and the remote half's questions in chat are invisible to the room. Five concrete adjustments close that gap for a 20-minute session.

Structured elaboration

1. Give remote a camera on the whole room, not just the presenter. A single wide-angle camera (or a laptop positioned to show the table) means remote participants can see who is speaking and read the room's reactions, instead of staring at one static face.
2. Share the actual slide deck through screen share, not a camera pointed at a projector. In-person and remote should see pixel-identical, readable content; a camera-on-a-screen view is blurry and a giveaway that remote is a second-class audience.
3. Narrate anything physical out loud, and share it digitally at the same time. If you hand out a printed one-pager or point at a physical whiteboard, describe what it says as you point, and simultaneously drop a PDF or photo of it into the chat so remote is never working from a description alone.
4. Deliberately alternate who you call on between the room and remote. Presenters default to whoever is physically in front of them; explicitly rotate ("let's hear from the room, then I want to check with our remote folks") so remote does not have to fight proximity bias to get a word in.
5. Assign someone in the room to actively watch the remote chat. In-person side conversations happen without remote ever knowing, and remote chat questions happen without the room ever knowing; one person whose job is bridging both channels catches what the presenter, who is busy presenting, will otherwise miss.

Worked example

A 20-minute customer briefing: minutes 0 to 2, confirm both groups can see the shared screen and hear clearly (fix any camera or audio issue now, not at minute 10). Minutes 2 to 15, present the material, pausing twice to explicitly invite remote input by name ("for our remote attendees, does this match what you were expecting?") and pointing the room-camera toward whoever is speaking. Minutes 15 to 20, close with the chat-monitor colleague reading out two questions that came in over chat before the meeting ends, so those questions get answered live rather than in a delayed follow-up email.

Trade-offs and pitfalls

Over-engineering the setup (multiple cameras, several apps) for a short 20-minute session can cost more setup time than the meeting itself; match the tooling to the stakes of the meeting. Rotating attention between room and remote too rigidly ("now the room, now remote, now the room") can feel mechanical if overdone; the goal is even access, not a strict metronome. Finally, assigning a chat-monitor only helps if that person is empowered to actually interrupt the presenter, not just silently log questions for later; agree on that authority before the meeting starts.

Direct answer

With an hour, I triage by what the audience can actually act on: the highest-value time goes to confirming the story the demo needs to tell actually works end to end, not confirming everything is production-correct. I check what would visibly break the demo or undermine trust in the room, and I explicitly decide what I'm choosing not to check because it isn't what this audience is evaluating today.

What I'd check (roughly 45 of the 60 minutes)

• Happy-path click-through, about 15 minutes: walk the exact sequence I plan to demo, twice, since a live click-order mistake is the single most visible failure in front of stakeholders.
• Core feedback and labels, about 10 minutes: confirm buttons say what they do and that loading and success states actually appear when triggered, since silence or a stuck spinner reads as "broken" to a non-technical audience even if it's just an unwired mock.
• A basic keyboard pass on the flow I'm demoing, about 10 minutes: can I actually tab through and trigger the parts I plan to show, since demos often get interrupted with "can you go back" or "can you click that instead," and I don't want to be caught unable to navigate off-script.
• Known landmines, about 10 minutes: anything already known to be broken or unfinished that's reachable from the happy path, so I can either fix it or plan my click-path around it.

What I'd deliberately skip, and why

• A full accessibility audit (screen reader pass, contrast checks across every screen): real work that deserves 30-45 minutes on its own; a stakeholder demo audience is evaluating direction and value, not compliance, so I'd flag it as a known open item rather than rush it.
• Cross-browser and cross-device testing: I'll demo on the one device and browser I control and explicitly skip the others, since the audience isn't going to interact with the prototype themselves in this meeting.
• Rare edge cases and error states, unless the demo's story specifically depends on them.
• Pixel-level visual QA, exact spacing, minor color inconsistencies: worth fixing later, but not worth demo-prep minutes when the room is judging the concept, not the polish.

Trade-offs and pitfalls

The risk of skipping too aggressively is being caught by a sharp-eyed stakeholder clicking off-script; the risk of not skipping enough is running out of time and never rehearsing the actual click-through, the one thing most likely to visibly fail. When in doubt, protect rehearsal time over completeness checks, since a smooth known path beats a technically more correct but unrehearsed one.

Direct answer

In a past role I pushed for two extra weeks before a rushed launch, and that extra time is what let us catch a real usability problem before it reached everyone, rather than shipping a metric win alongside a support cost we hadn't budgeted for.

Situation

Three weeks before a marketing campaign slot, leadership wanted to ship a redesigned onboarding flow fast enough to catch the promotional window. My qualitative research (a round of customer interviews) and the instrumentation needed for a proper controlled test were both still incomplete.

Task

I needed to decide whether to let the rushed timeline stand or make the case for more time, knowing the pushback would come from marketing and from the executive who owned the launch date.

Action

Before I went to the executive sponsor, I aligned the two partners whose evidence would carry more weight than mine alone: the engineering lead, who confirmed an unresolved instrumentation gap meant we'd be flying blind on a key drop-off point, and the support lead, who flagged which ticket categories were most likely to spike if we shipped the current confusing step unchanged. With that evidence assembled, including partial interview notes pointing at a specific unresolved point of confusion and the instrumentation gap itself, I put together a short risk-versus-cost comparison: the two-week delay costs a marketing slot; shipping now on an untested assumption risks a common workflow breaking and driving up support volume. I proposed a middle path, two more weeks to finish the outstanding interviews and instrumentation, then a release behind a feature flag with a small initial rollout so we could catch problems before everyone saw them.

Result

The executive accepted the compromise once engineering and support were already visibly on board, not because I was still the lone voice asking for delay. The extra research surfaced one real point of confusion that we fixed before the wider release. Activation ended up landing solidly ahead of where the rushed version was projected, and we didn't see the support-ticket spike the rushed version had risked.

Looking back

I'd build a research-versus-launch tradeoff conversation into the roadmap earlier, so we're not negotiating time at the last minute, and I'd get engineering's and support's read on risk before the crunch rather than during it, since that's what actually moved the decision in the end, not my own argument alone.

Clarify goals & constraints

• Users must navigate deep category trees quickly; content updates frequently; mobile screen real-estate limited. Prioritize fast discovery, predictable back behavior, robust deep-linking, and quick re-orientation after context switches.

High-level navigation pattern

• Search-first home: prominent search bar with recent queries and dynamic suggestions; category entrypoints below as cards (top categories + curated shortcuts).
• Two-pane hierarchy: primary list (categories) + secondary detail pane (subcategories or content) via modal/partial-sheet to avoid full context switch.
• Persistent bottom nav: 3–5 top-level destinations (Home/Search/Saved/Profile).

Back-stack & session state

• Use linear back-stack for modal/partial-sheet navigation; tapping category pushes new state but opening item from external deep-link creates a separate resumeable task stack.
• Persist session in local storage: current path, scroll positions, unsaved filters; restore on app resume or after crash.

Deep-linking

• Canonical URLs for every node; open deep-links into content with a “breadcrumb chip” at top showing compact path; allow users to expand path to full category sheet.
• If category data missing due to updates, show graceful fallback with related suggestions and “Go to parent” affordance.

Alternatives to breadcrumbs

• Use breadcrumb chip + contextual chip trail inside header, and a collapsing “You are here” strip showing 1–3 ancestors.
• Use a visual tree-preview (mini-map) accessible from header to jump to sibling branches.

Re-orientation after context switches

• Show transient contextual toast: title + compact path + “Back to where I was” button.
• Highlight changes (new/updated content badges) and animate scroll-to-restored position.
• Provide history/recent activity panel in search and home.

Research & validation

• Prototype flows and run task-based usability tests focusing on re-orientation and deep-link entry.
• Metrics: time-to-find, drop-off after deep-link, resume success rate, filter retention.

Trade-offs

• Partial-sheets reduce full navigation depth but add complexity to state-sync; prioritize for mobile to keep users anchored.

Direct answer

Credibility with people who have no track record with you is earned in the first few interactions, not argued for. The fastest reliable path is to listen before recommending anything, make your reasoning visible rather than just your conclusions, and deliver one small, real result quickly, before you ever ask them to trust a bigger claim.

Structured elaboration

A framework for the first interactions with a new stakeholder or team.

1. Intake before opinion: understand what decisions they're actually trying to make and what's gone wrong for them before, before offering any recommendation.
2. Show your work: when you do produce something, make the validation visible (trace a number back to its source live, walk through how a result was derived) instead of asking them to trust a polished output.
3. Deliver a small, real win fast: a scoped result within the first couple of weeks does more for trust than a comprehensive plan that ships in month two.
4. Telegraph how you handle being wrong: tell them up front how you'll flag it if something in your work turns out to be off. People trust someone who has already shown you a plan for your own mistakes.

The first 30 days. New cross-functional partners are evaluating you the whole time, not just at the big review. Being proactive about the relationship in the first 30 days, rather than waiting for a natural moment, is itself a credibility move. A first 1:1 with a new partner can open with something like: "What decisions are you trying to make in the next month that you don't feel confident about today?" followed by "What's gone wrong before when someone tried to help with this?" Both questions do real work: the first surfaces what would actually count as a win to them, the second surfaces the specific way trust was broken before, so you don't repeat it by accident.

Three behaviors that quietly erode credibility across teams, and the remediation for each:

Credibility repair is a different problem from rapid trust-building, and worth naming separately. Rebuilding credibility across engineering, product, and customers after an architecture decision failed in production is credibility repair, not the repair of a single personal relationship: it spans multiple functions at once, each of which needs something different. Engineering needs an honest technical postmortem without blame-shifting. Product needs clear, early communication about impact and timeline. Customers need a concrete remediation plan and a channel that doesn't go quiet. Treating this as "smoothing over one relationship" misses that trust has to be rebuilt with several audiences in parallel, each judging you by different evidence.

Worked example

Situation: in the first month partnering with a new team (the fraud-risk team, which had just started requesting weekly modeling support from the analytics group for the first time), the working relationship started skeptical, because past deliverables from this kind of collaboration had shipped late and with numbers nobody trusted.

Actions: an early 30-minute intake conversation confirmed exactly which decisions the partner team needed to make (specifically, which transaction-flagging threshold to set for the coming week) and which metrics actually mattered to them (the false-positive rate on flagged transactions, not just the raw flag count), rather than assuming. A one-page plan with milestones and explicit validation steps went out so expectations were unambiguous. A working version, a weekly false-positive-rate dashboard for the fraud-risk team's review queue, shipped inside the first two weeks, and in the walkthrough, a couple of numbers the partner flagged as surprising (the false-positive rate for one transaction category showing 22% instead of the roughly 8% they expected) were traced live, back to the source data, in the room, instead of being defended from memory. The trace showed the 22% figure was correct: a recent change to that category's flagging rule had not been backed out of the historical comparison period, inflating the apparent rate.

Resolution: the partner team began using the dashboard for real weekly threshold decisions within the two-week window. What changed their minds wasn't the polish of the output, it was watching the 22% number get traced back to its source live and seeing that the plan they'd agreed to up front was the plan that got delivered.

Trade-offs & pitfalls

• Rapid trust-building tactics (intake, quick win, visible validation) and credibility-repair tactics (postmortem, cross-function communication, remediation plan) are not interchangeable; using a "quick win" playbook after a public failure reads as minimizing what happened.
• An intake-only approach that never produces anything can itself read as stalling; the first small delivery needs to land within roughly the same window as the intake conversation, not months later.
• Under-promising protects credibility but can look like low ambition if you don't also communicate what you're deliberately holding back on for now.

Direct answer. Building a minimal accessible color palette across multiple brand colors means computing and documenting the actual contrast ratio of every foreground/background pairing that will realistically occur, then producing a small set of verified-safe token variants (a "text-safe" darkened or desaturated version of each brand hue) rather than assuming the marketing-approved brand swatches will happen to pass.

The process with engineers. Start from the existing brand hues, compute each one's contrast against the actual backgrounds it will sit on (white, dark-mode surface, etc.), and for any pairing that fails, produce a systematically darkened or desaturated variant of the SAME hue (adjusting lightness in HSL space keeps the hue recognizable) rather than picking an unrelated replacement color; verify the adjusted variant passes, and only then add it to the shared token set engineers actually consume.

Worked example, computed with a self-contained script. I ran the WCAG relative-luminance contrast formula against a representative brand palette on a white background (a note for UX, Product, or UI Designer readers: you don't need to trace the gamma-correction math in the function below line by line, the part that matters is the 'Actual output' ratios reported right after it):

def srgb_to_linear(c):
    c = c / 255.0
    return c / 12.92 if c <= 0.03928 else ((c + 0.055) / 1.055) ** 2.4

def relative_luminance(hexval):
    hexval = hexval.lstrip('#')
    r, g, b = int(hexval[0:2], 16), int(hexval[2:4], 16), int(hexval[4:6], 16)
    return 0.2126 * srgb_to_linear(r) + 0.7152 * srgb_to_linear(g) + 0.0722 * srgb_to_linear(b)

def contrast_ratio(hex1, hex2):
    l1, l2 = relative_luminance(hex1), relative_luminance(hex2)
    lighter, darker = max(l1, l2), min(l1, l2)
    return (lighter + 0.05) / (darker + 0.05)

colors = {'brand-purple': '#8B5CF6', 'brand-purple-dark': '#6D28D9', 'brand-green': '#10B981', 'brand-green-dark': '#047857'}
for name, hexval in colors.items():
    print(name, round(contrast_ratio(hexval, '#FFFFFF'), 2))

Actual output: brand-purple on white is 4.23:1 (passes AA normal text at 4.5:1? no, it does not, 4.23 < 4.5, so it passes only for large text at the 3:1 threshold); brand-purple-dark is 7.10:1 (passes AA and AAA normal text); brand-green is 2.54:1 (fails even the 3:1 large-text floor, unusable for text at any size); brand-green-dark is 5.48:1 (passes AA normal text). This concretely shows why a single brand hue can't be trusted for text: the base green fails outright, while its darkened variant comfortably passes, and the purple only passes for large text, so a naive "one color, one use everywhere" token model would ship real failures.

Tooling and technique. Adjust lightness in HSL rather than RGB directly, since HSL lightness maps more predictably to perceived brightness and keeps the hue angle (and therefore brand recognizability) fixed while you search for a passing lightness value; the contrast_ratio function above is the reusable core of that tooling, so automate the check around it (a small script or a Style Dictionary build-time lint) so a future token addition or brand refresh can't silently reintroduce a failing color without the build catching it.

Trade-offs and pitfalls. Treating this as a one-time exercise (compute once, ship, forget) misses that brand palettes get extended over time; the durable fix is a build-time contrast check on every token addition, not a one-off audit.

Direct answer

Here's a realistic shape this failure takes: a team runs a test, the result is a small, not-quite-significant lift, and instead of accepting an inconclusive result, someone extends the test past its planned window and slices the data by a new segment until one slice crosses the significance threshold, then reports that slice as the finding. Confirmation bias (the tendency to notice and trust evidence that matches what you already expected, while explaining away evidence that doesn't) sets the motive; p-hacking (reshaping an analysis, through extra time, extra segments, or dropped outliers, until something crosses a "statistically significant" threshold by chance, then reporting only that result) is the mechanism. Both surface the same way after the fact: a shipped change that doesn't hold up.

A concrete version of the failure

A design team redesigns onboarding and runs an A/B test (a controlled comparison of the new flow against the old one) with a pre-planned two-week window, a pre-registered significance bar of p < 0.05, and a single primary metric, day-7 activation rate. Traffic to the flow runs about 5,000 users per arm per week, so the planned readout lands on roughly 10,000 users per arm. At two weeks, day-7 activation comes in at 41.2% for the treatment arm versus 40.1% for control, a 1.1 percentage-point lift. Put through a two-proportion z-test at that sample size, that gap gives z = 1.58 and p = 0.11, short of the pre-agreed 0.05 bar. Instead of shipping "inconclusive, here's what we'd test next," the team extends the test for another week without writing that decision down anywhere, and someone also starts slicing the data by device type "just to look."

The extra week is worth watching on its own. At three weeks the arms have roughly 15,000 users each, the gap is still about the same size, 41.5% versus 40.4%, and the bigger sample alone pulls the p-value from 0.11 down to 0.053. It still has not crossed, and that near-miss is exactly what makes the next move feel reasonable. The device cut is where it gives way. Mobile is about 60% of the sample, roughly 9,000 users per arm, and mobile activation reads 44.4% for treatment against 42.8% for control, a 1.6 percentage-point lift at p = 0.03. The remaining 40% on desktop, about 6,000 per arm, reads 37.15% versus 36.8%, a 0.35 point difference at p = 0.69, which is nothing. The two slices do blend back to the overall three-week numbers, so nothing looks off on inspection: 0.60 x 44.4 + 0.40 x 37.15 = 41.5, and 0.60 x 42.8 + 0.40 x 36.8 = 40.4. That mobile slice becomes the headline of the launch readout; the extension and the segment cut are never mentioned, and the team convinces itself the mobile result is what they expected all along, which is confirmation bias explaining why nobody questioned it in the room.

Notice how little work it took. One unplanned week plus one unplanned two-way split moved a result from p = 0.11 to p = 0.03 without any new effect coming into existence. That is the entire mechanism: every additional look is another chance for noise to line up. A rough feel for the cost, treating the two device slices as independent tests, which flatters the team because in reality they share the same underlying data: two shots at a 0.05 threshold give a false-positive rate of 1 - 0.95^2, about 9.8%, and adding the unplanned extension as a third look takes it to 1 - 0.95^3, about 14%. The threshold on the readout still says 0.05. The real one is nearly three times that.

How the team recognized it

The tell came four to six weeks after full rollout. At full traffic that window covers roughly 50,000 users, compared against a matched pre-launch window of about the same size, and day-7 activation across all users sat at 40.3% against the pre-launch baseline of 40.1%: a 0.2 point difference, p = 0.52. The p-value is not the useful part; the interval behind it is. The 95% confidence interval on that difference runs from about -0.4 to +0.8 percentage points, and a genuine 1.6 point mobile lift on 60% of users would have to show up as roughly a 0.96 point lift overall, which sits outside that interval. The post-launch check carried about five times the per-arm sample of the planned two-week readout, so this is not an underpowered null that failed to detect a real effect. It is a direct contradiction of the "it worked" story from the readout.

A skeptical team member then pulled the original experiment plan and compared it line by line to what actually happened: the planned duration didn't match the actual one, the planned primary metric wasn't the one that shipped in the readout, and the mobile-only segment was never named as a hypothesis before the data existed. None of the three matched, which is the specific pattern p-hacking leaves behind: a result that only exists because the analysis kept changing until something looked significant.

Surfacing it turned out to be a separate problem from spotting it, and it is the half teams get wrong. What worked was taking the plan-versus-readout comparison back to the same forum where the win had been announced, rather than raising it privately, and presenting it as a process failure rather than as somebody's mistake: the plan allowed an undocumented extension, and the readout template had no field for "what changed after launch," so the gap was invisible by design. The claim was then explicitly retracted rather than left to quietly age out of the roadmap, and the mobile hypothesis was re-entered in the backlog as an untested idea. Framing it as "our process let this through" is what makes the next person willing to raise the same flag; framing it as "who wrote this readout" is what guarantees nobody does.

Changes to prevent it recurring

1. Pre-register before launch: write down the primary metric, the planned duration or sample size, and the stopping rule in a shared doc before anyone sees results, not after.
2. Hold to the stopping rule: review at the planned checkpoint and decide then, rather than checking daily and extending whenever the number looks close.
3. Treat any subgroup or exploratory finding discovered after the fact as a new hypothesis, to be confirmed with its own fresh experiment, never shipped as a conclusion from the same data that generated it.
4. Add a second reviewer, a researcher or a peer designer who wasn't running the test, to read the write-up against the original plan before a launch decision is made, specifically checking whether anything (the metric, the duration, the segment) changed after the data came in.
5. If the team genuinely needs to look early or to cut by segment, budget for it in the threshold instead of taking the extra looks for free: pre-declare the segments you will examine and tighten the bar accordingly (with two device slices, roughly 0.025 each rather than 0.05), or use a sequential design with a spending rule that permits interim peeks at a stated cost. The point is not that extra looks are forbidden, it is that they have a price and it should be paid up front.

Trade-offs and pitfalls

Extending a test or looking at a subgroup isn't wrong by itself; both are legitimate exploratory moves. The failure is presenting an exploratory finding with the confidence of a pre-planned, confirmatory one. The real trade-off is speed against rigor: pre-registration and a fixed stopping rule cost time and will feel like friction under launch pressure, and teams will be tempted to peek early and act on whatever looks good that week. Weigh that friction against what it buys, though. The cost of the failure above was not one bad onboarding flow; it was that every earlier result the team had shipped became suspect, because none of them had a plan on file to check against. The cultural fix matters as much as the procedural one: a team has to reward "this was inconclusive, here's what we'd check next" as a legitimate, even respected outcome, not treat every test that doesn't find a lift as a failure to be quietly reworked until it does.

Direct answer

Developmental feedback, whether it lands in a formal performance review, a string of recurring code-review comments, or a candid conversation with a cross-team peer, only becomes useful once it's turned into a concrete plan with real milestones, not just a private intention to "do better." Structuring that plan around short checkpoints (for example, roughly 30, 60, and 90 days out), pairing each one with a way to actually show progress, and checking back with whoever raised the feedback rather than assuming the plan alone closes the loop is what separates a real development plan from a good intention that fades.

Structured elaboration

Clarify the specific behavior behind the label. A word like "ownership," "testing," "communication," or "business impact" can mean many different things in practice. Ask for a concrete example of what prompted the feedback, since the plan needs to target the actual behavior, not the label attached to it.

Build a milestone plan with visible checkpoints. An early checkpoint (roughly the first month) is about smaller, low-stakes practice: trying the specific behavior somewhere the cost of a misstep is low, and, where useful, pulling in a resource deliberately, whether that's a course, a mentor, or pairing with a colleague who's strong in that exact area, rather than just resolving to try harder. A middle checkpoint (roughly two months in) is about applying it in a real, higher-stakes setting and actively gathering a read on whether it's landing. A later checkpoint (roughly three months in) is about showing the behavior consistently across contexts, not just with one team or one person who already knows to expect it, and bringing concrete evidence back to whoever gave the original feedback.

Use resources deliberately rather than relying on willpower. A mentor, a targeted course, or pairing with someone strong in the gap area is usually far more effective than simply trying harder at the old approach; naming the specific resource used is part of what makes the plan concrete rather than aspirational.

Create your own way to see progress along the way. Feedback that matters doesn't only arrive at the next formal review; it can also show up informally, in a comment from a colleague or a passing remark. Building in a lighter self-check, or asking a trusted colleague to flag it if the old pattern resurfaces, keeps the plan honest between the big checkpoints.

Worked example

A manager's review notes that communication with other teams needs work, and the specific example given is that cross-team updates tend to arrive late and are too dense to act on quickly. In the first month, the update format changes to lead with the ask and the deadline, and early drafts get a quick review from a mentor before sending, as a low-stakes way to practice the new habit. In the second month, that habit gets applied in a real, higher-visibility setting: proactively posting a mid-sprint update to a cross-team channel before anyone has to ask for one, and paying attention to whether people are actually finding it clearer. By the third month, after several cycles of this, the pattern shows up in the threads themselves: cross-team updates that used to draw a "can you clarify" reply on roughly half of them are drawing one on maybe one in ten, and a direct check-in with a cross-team peer confirms updates now feel timelier and clearer. Both the count and the peer's read get brought back to the manager at the next check-in as evidence the specific behavior has changed, not just a claim that it has.

Trade-offs and pitfalls

Writing a plan and not revisiting it until the next annual review lets the good intention quietly lapse with nobody the wiser. Choosing milestones that describe activities (attended a course, read a book) rather than evidence that the underlying behavior actually changed makes the plan easy to complete without the feedback ever really landing. The other common failure is treating a specific example as an attack to be argued away instead of the concrete anchor it actually is; escalating defensively over one instance of feedback wastes the opportunity the specific example was giving you to target the plan precisely.

Direct answer

Model context-dependent values as a composition of a small set of intent-based base tokens (surface, overlay) and a small set of context modifiers (card, modal), resolved together at build or render time, rather than creating a separate token for every property-by-context combination. The namespace stays small because contexts are reusable modifiers, not one-off tokens.

Structured elaboration

Why naive per-combination tokens explode
If elevation alone needs a distinct token for every host component (card, modal, dropdown, tooltip, popover), and the system has, say, four elevation levels and six contexts, that's already 24 tokens for one property, and every new context multiplies the count further. The combination is the problem, not the base values.

Two-layer model

1. Base semantic tokens: express intent, not context. elevation.surface (a subtle resting shadow) and elevation.overlay (a strong shadow for content that floats above everything else) are the only two base values most systems actually need.
2. Context modifiers: a small, named set of scale/offset adjustments. context.card might dampen the base shadow (it's a resting element), context.modal might amplify it (it needs to visually separate from the whole page).
3. Composition: a resolver combines base token and modifier at the point of use, rather than a designer or engineer having to remember a bespoke value per context.

Precedence for stacked contexts
When a card renders inside a modal, apply modifiers in a documented, fixed order (innermost first) rather than an ad hoc combination, so a component author never has to guess which modifier wins.

Worked example

Base tokens:

:root {
  --elevation-surface-y: 2px;
  --elevation-surface-blur: 8px;
  --elevation-surface-alpha: 0.12;
  --context-card-scale: 0.8;
}

Composition:

.card {
  --elev-y: calc(var(--elevation-surface-y) * var(--context-card-scale));
  box-shadow: 0 var(--elev-y) var(--elevation-surface-blur) rgba(0, 0, 0, var(--elevation-surface-alpha));
}

The resolved value:

No card-elevation token was ever authored, it's the composition of one base token and one reusable modifier, and the same context.card modifier applies to any other property (border-radius, opacity) a card variant needs to dampen, without a new token per property.

Trade-offs & pitfalls

Composition adds a layer of indirection: reading .card's final box-shadow value now requires resolving two tokens instead of reading one, which is a real cost for a component author debugging a visual issue without tooling support (a resolver preview in Figma or a browser devtools helper mitigates this, but only if someone builds it). The model also breaks down if teams start inventing new contexts ad hoc instead of reusing the documented set, at that point the namespace explosion just moved from properties to contexts. The right calibration is to keep the context list intentionally small and centrally owned, adding a new context should require the same review a new base token would.

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.