Entry Level UI Designer Interview Preparation Guide - FAANG Standard

Direct answer

The core move in an incident explanation to a non-technical audience is separating three layers up front: what happened (in plain terms, no root-cause mechanism), what it meant for them (impact, in terms they already track), and what's being done about it, then deliberately leaving out anything that doesn't serve one of those three. Below is an incident where I did that under time pressure, including delivering it live to a mixed engineering-and-business audience.

What to include, what to leave out, and how to decide

• Lead with impact, not sequence. Legal, sales, and executives care about what happened TO THEM first, which customers, how long, what's the exposure, the technical timeline is useful evidence, not the headline.
• Deliberately exclude logs, stack traces, and internal service names; they add authority for an engineering audience and add nothing but confusion for this one. A useful test: if a detail doesn't change what the listener should do next, leave it out.
• Give the cause in one plain sentence with no jargon, something like "a recent configuration change made one of our systems too slow to respond to a partner service in time," rather than either omitting cause entirely (which reads as evasive) or over-explaining the mechanism.
• When delivering this live rather than in a written report, whether it's a hallway update or presenting a postmortem verbally to a room that mixes engineers and business stakeholders, pause after the impact statement for questions before moving to cause. People worried about impact can't absorb a root-cause explanation until that worry is addressed first.

Worked example

Situation: during a high-traffic sales period, our payment service began intermittently failing checkout requests for roughly ninety minutes. Legal, sales leadership, and the executive team needed an explanation quickly.

Task: explain what happened clearly enough for them to act, communicate with affected customers, assess any obligations, decide on immediate next steps, without either alarming them with irrelevant detail or minimizing the impact.

Action: I opened with impact, in the terms they track: which customers were affected, for roughly how long, and that the issue was fully resolved and being watched closely. I gave the cause in one sentence: a recent configuration change made our payment service too slow to respond to our external payment gateway in time, causing some checkout attempts to fail. I described what we did in plain terms (reverted the change, increased how long we wait before giving up on a slow response, added an automatic circuit breaker so a slow dependency can't cascade into a wider outage) and what we were doing next (a deeper review, with a fuller technical writeup available to anyone who wanted it). I left out the specific error codes, service names, and configuration parameter, none of which changed what legal, sales, or the executives needed to do next. I paused for questions right after the impact statement, before moving on, and answered a legal question about customer notification obligations directly instead of routing it back to engineering jargon.

Result: legal and sales left with a clear, accurate picture of exposure and could communicate confidently with affected customers; the executive team approved the follow-up work (the circuit breaker and review) without needing to dig into implementation detail themselves, and a fuller technical postmortem was made available separately for the engineering team that wanted the mechanism-level explanation. I learned that pausing for questions right after the impact statement, before cause, kept people from tuning out a cause explanation they weren't ready to hear yet.

Trade-offs and pitfalls

Leaving out technical detail can read as evasive if you do it silently; I said "I'm not going to walk through the technical internals here, I'm glad to share those separately" so the omission was visible on purpose rather than hidden. The other pitfall is understating severity to keep the room calm, that erodes trust the moment the real scope becomes clear later. State the honest impact even when it's uncomfortable, and let the "what we're doing about it" section carry the reassurance instead of the impact statement itself.

Direct answer

Use STAR, and be ready for the fact this scenario shows up with different flavors depending on your field: the constraint that forces the pivot might be a compute or ad-spend budget, a compliance or regulatory trigger, an architecture limit, or a competitive shift. Whichever flavor your real story has, cover the same four things: what you adapted, what you reprioritized in flight, what trade-off you communicated and to whom, and how you checked afterward that the pivot actually delivered value rather than just assuming it did.

STAR skeleton to fill in

• Situation: the original plan and the trigger for the shift (leadership change, urgency, client need, or roadmap shift).
• Task: what you were responsible for delivering.
• Adapt the plan: what changed structurally, not just "we reprioritized."
• Reprioritize in-flight work: specifically what you paused, cut, or kept, and which requirement you refused to cut and why.
• Communicate trade-offs: what you told each stakeholder who owned a different constraint (cost, timeline, compliance, quality), not a single generic update.
• Deliver value and measure it: what you shipped given the new priorities, and what you checked afterward to confirm the pivot held up.

Worked example instance

Situation: midway through a three-week plan to train and deploy a new fraud-detection model feature, two things hit at once: a new regulatory request required a documented fairness audit before any model touching credit decisions could ship, and a company-wide cost push cut the quarter's compute budget by 30%. Adapt the plan: I paused two of five planned hyperparameter-sweep experiments, the ones consuming the most compute for marginal gains, and switched from a broad grid search to a narrower, warm-started search seeded from the best prior model's parameters. The original sweep plan was budgeted at 640 graphics-processing-unit hours (GPU-hours, a standard way to measure compute usage) across five experiments; the narrowed plan used 210 GPU-hours across two experiments plus the audit's own compute, a 67% reduction (640 minus 210, divided by 640), measured on the same GPU-hour basis for the same job accounting period. Reprioritize, non-negotiable requirement: the fairness audit ran on the full 12,000 case held-out evaluation set, not a sampled-down version, so the audit's statistical validity wasn't compromised by the cost pressure; the exploratory hyperparameter sweep, the lower-stakes item, is what I cut instead. The audit also required re-architecting part of the pipeline to log per-decision feature attributions, an added four engineering days. Communicate trade-offs: I presented one joint plan to both the sales stakeholder, who owned the client delivery date, and the engineering stakeholder, who owned the compute budget: a two-day slip (17 business days instead of the original 15), full fairness audit, and a reduced hyperparameter search, at no additional compute cost beyond the already-cut 210 GPU-hour budget. I was explicit that skipping the audit to hit the original date wasn't actually an option once it was flagged as a regulatory requirement, not a soft preference. Deliver value: we shipped two days late, audit complete, under the new compute ceiling, and the narrowed search's best model matched the broad search's baseline within 0.4 percentage points of area under the ROC curve (AUC, a measure of how well the model separates good from bad cases), so the compute cut didn't quietly cost accuracy. Measure afterward: six weeks post-launch, I compared the shipped model's live precision and recall against the pre-pivot baseline to confirm the narrower search hadn't cost anything in production that the offline holdout missed, and I kept the audit's finding, no significant disparate impact detected across the three protected groups examined, as a concrete artifact for the next time the regulatory question came up.

Second, shorter example (different discipline): a field-marketing team running a six-week campaign gets a leadership-driven pivot when a competitor announces a similar product, creating urgency to move up the launch. The lead cuts two lower-priority content pieces, keeps the core launch asset shipping on time as the non-negotiable requirement, tells the sales stakeholder who needed the materials exactly what got cut and why, and afterward checks whether the compressed review window introduced more post-launch corrections than usual, to decide whether that shortcut is safe to repeat.

Trap to avoid

The mediocre answer stops at "we reprioritized and delivered," without ever returning to check whether the pivot actually held up, and treats "communicate trade-offs" as one announcement rather than a decision made jointly with the specific stakeholders who each owned a different constraint.

My process starts from the brand's voice, not from a list of favorite fonts. A typeface carries personality before a user reads a single word of copy, so the first question is what that personality needs to be (serious and precise, warm and approachable, playful), and only then do I start narrowing candidate typefaces.

The selection process

1. Narrow by category and personality. Serif faces tend to read as traditional, trustworthy, or editorial; sans-serif faces read as modern and clean; geometric sans faces (built from simple, consistent shapes) often read as confident and tech-forward. I shortlist two or three candidates that match the brand's intended tone.
2. Check technical constraints early, before falling in love with a face: does it support every language and character the product needs, does it come in enough weights (light, regular, medium, bold) to build a real hierarchy, is it available as a variable font (one file that can smoothly produce many weights, keeping page-load weight down) or does it need several separate font files, and what does licensing cost at the company's scale.
3. Build a type scale, a set of font sizes with a consistent ratio between steps, so headings, body text, and captions all feel like they belong to one deliberate system instead of being picked ad hoc.
4. Set line-height (the vertical space taken up by each line of text) and measure (how many characters fit on one line) for each size, since a typeface that looks great as an isolated headline can become hard to read as dense paragraph text if the line-height and measure aren't tuned for it.

A worked example

Using a base body size of 16px, with sizes rounded to clean numbers on the interface's spacing grid rather than one exact ratio multiplied out at every step. The real growth from one size to the next actually varies: Caption to Body is a 33% jump (12 to 16), Body to H3 is a 50% jump (16 to 24), H3 to H2 is a 33% jump (24 to 32), and H2 to H1 is a 25% jump (32 to 40, the only step that's a true "major third," 1.25 ratio). In practice, landing on numbers that sit cleanly on the shared grid usually matters more than forcing one exact ratio through every single step:

• H1: 40px, line-height 48px (used for a page's single main heading)
• H2: 32px, line-height 40px (section headings)
• H3: 24px, line-height 32px (sub-section headings)
• Body: 16px, line-height 24px (paragraph text; a 1.5x line-height is a solid default for anything meant to be read at length)
• Caption: 12px, line-height 16px (metadata, timestamps, helper text)

For weights, I'd typically use bold or semibold for H1 through H3 to reinforce their size-based hierarchy, and regular weight for body and captions, since long paragraphs set in bold become fatiguing to read.

Balancing readability, brand tone, and platform constraints

A highly distinctive display face often has to be reserved for large headline sizes only, since its personality-driving details (unusual curves, tight spacing, decorative strokes) can become illegible at small sizes; a separate, more neutral workhorse typeface usually carries body and caption text instead. On mobile platforms, I also weigh whether a fully custom brand font is worth its load-time and rendering cost versus leaning on the platform's own system font (which renders instantly and respects a user's own text-size settings) for dense in-app text, saving the custom face for marketing moments where its personality earns its keep.

Direct answer

The mobile overlay drawer is modal, so it needs a full focus trap: focus moves into the drawer when it opens, Tab/Shift+Tab cycle only within it while it's open, and focus returns to the control that opened it when it closes. The desktop persistent sidebar is not modal, it's a permanent part of the page, so it must never trap focus; a keyboard user should be able to Tab from the sidebar into the main content and back as part of the normal page flow, exactly like any other section of the page. Touch gestures (swipe to open or close) are an addition on top of button and keyboard controls, never a replacement for them, since a keyboard-only user has no swipe to fall back to.

Structured elaboration

What changes between the two layouts

Focus trap mechanics on mobile

On open: move focus to the first meaningful focusable element inside the drawer (often the first nav link, or a close button if one is visually present), and mark everything outside the drawer inert (or aria-hidden="true" plus tabindex="-1" on focusable siblings, inert is the more complete modern approach since it also blocks pointer and find-in-page). While open: intercept Tab at the last focusable element to wrap to the first, and Shift+Tab at the first to wrap to the last, so focus can never escape into the hidden background. On close (via close button, Escape, backdrop click, or swipe): restore focus explicitly to the element that opened the drawer, don't just let it fall to <body>, or a keyboard user loses their place entirely.

Why the desktop sidebar must not do any of this

A persistent sidebar is structurally just another landmark on the page (<nav>), the same category as a header or footer. Trapping focus inside it, or moving focus into it automatically, would break the normal, predictable Tab order a keyboard user relies on to move through the whole page. The single most common accessibility bug in "responsive" nav components is reusing the mobile drawer's focus-trap logic unconditionally on desktop, silently turning a permanent sidebar into something that behaves like it's stuck open and modal.

Reconciling touch gestures with keyboard-only users

Swipe-to-open and swipe-to-close are conveniences layered on top of, never instead of, an explicit trigger button and Escape support. A gesture-only implementation (drawer only opens via swipe, no visible button) has no keyboard equivalent at all, which fails outright for keyboard-only users and for many switch-access and voice-control users whose input doesn't map to a swipe gesture. The trigger button, Escape to close, and the swipe gesture should all lead to the exact same code path (the same open/close function with the same focus management), so there's no risk of the gesture path skipping the accessibility handling the button path does correctly.

Worked example

A minimal focus-trap helper, the shape that gets wired to the mobile overlay's open/close, not the desktop sidebar:

function openDrawer(drawer, trigger) {
  const focusable = drawer.querySelectorAll(
    'a[href], button:not([disabled]), input, [tabindex]:not([tabindex="-1"])'
  );
  const first = focusable[0];
  const last = focusable[focusable.length - 1];

  drawer.hidden = false;
  document.getElementById('main-content').inert = true;
  first?.focus();

  function trapTab(event) {
    if (event.key !== 'Tab') return;
    if (event.shiftKey && document.activeElement === first) {
      event.preventDefault();
      last?.focus();
    } else if (!event.shiftKey && document.activeElement === last) {
      event.preventDefault();
      first?.focus();
    }
  }

  function onEscape(event) {
    if (event.key === 'Escape') closeDrawer(drawer, trigger);
  }

  drawer.addEventListener('keydown', trapTab);
  drawer.addEventListener('keydown', onEscape);
}

function closeDrawer(drawer, trigger) {
  drawer.hidden = true;
  document.getElementById('main-content').inert = false;
  trigger.focus(); // restore focus to the control that opened it
}

openDrawer and closeDrawer are the same functions called by the trigger button's click handler, the Escape listener above, and a swipe gesture handler, so all three entry points guarantee identical focus behavior instead of the gesture path silently skipping the trap or the restoration step.

Trade-offs & pitfalls

• Reusing one component implementation for both layouts without conditioning the focus-trap logic on which mode is active is the most common bug class here: it's easy to ship a drawer that traps focus correctly on mobile and then, unnoticed, does the exact same trapping on desktop where the sidebar is persistent, breaking normal keyboard navigation for every desktop user.
• aria-hidden on background siblings is the older pattern and still works, but doesn't block pointer interaction or in-page search the way inert does; inert is the more complete solution where browser support allows it, with aria-hidden plus disabled tabindex as the fallback.
• Forgetting to restore focus to the specific trigger element (letting it fall back to <body> on close) is a small-looking bug with an outsized cost for screen reader and keyboard users, who lose their position on the page and have to re-navigate from the top.
• Gesture-only entry points (no visible open button, relying entirely on an edge swipe) are a common mobile-web pattern borrowed from native apps that fails accessibility outright on the web, always ship the explicit button alongside the gesture, never instead of it.

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

Building a learning culture beyond 1:1s means putting repeatable, low-friction habits in place so sharing is the default rather than a favor. What that actually looks like differs a lot depending on the starting point: growing a habit on a team that has none yet is a different job than repairing a team that's already knowledge-hoarding or blame-heavy.

Concrete mechanisms and when to use them

• Protected time. A small, explicitly scheduled block for learning or side improvements, documented so it isn't the first thing that gets cut under deadline pressure.
• Recurring show-and-tell sessions with rotating presenters. Forces more people to teach, not just attend, which is where retention actually happens.
• Pair or mob work as a distinct mechanism. This is not the same as a scheduled talk. It transfers tacit, in-the-moment judgment (why you chose this approach, what you noticed that made you suspicious) that a prepared presentation usually strips out.
• Living documentation habits. Write things down where the next person will actually find them, and treat updating docs as part of finishing the work, not an optional extra.
• Cross-functional shadowing and recognition. Exposure to how work is used downstream, plus visibly crediting people who share, reinforces that this is valued behavior, not wasted time.

Starting condition changes the plan

If the culture is already blame-heavy or knowledge-hoarding, launching a program on top of it usually fails, because the underlying incentive (don't expose what you don't know, don't give away your leverage) is still active. The first move there is addressing the trust deficit directly: blameless review of mistakes, visibly not punishing people for the time spent teaching others, and naming the hoarding pattern if a specific person is doing it deliberately.

The resistant individual case

Sometimes the blocker isn't a missing structure, it's one specific person, often senior, who prefers working alone and resists mentoring or sharing. A reasonable sequence: first understand why (overloaded? burned by a bad past experience being open? never actually rewarded for it?), then make sharing low-cost and optional (asynchronous write-ups instead of live sessions), then tie it to explicit expectations if the role genuinely requires a multiplier effect at that level, and only if it persists despite support and clear expectations, treat it as a performance conversation rather than indefinite soft nudging.

Worked example

On a team where the same questions kept getting asked repeatedly in private messages instead of anywhere visible, the actions taken were: a weekly rotating show-and-tell, a pairing rotation on non-critical work, and a push to answer questions in a shared channel instead of DMs. One senior engineer initially opted out of presenting; a private conversation surfaced that they'd had a talk go badly in a previous job and hadn't tried again since. Starting them with a low-stakes written walkthrough instead of a live talk got them re-engaged. Over the following weeks, the same question started getting asked once in the open channel instead of five times in private, and people began proposing small improvements without being asked first.

Trade-offs and pitfalls

A common junior move is to launch one big formal program and treat it as solved (checkbox mentality) instead of building the habit into the normal rhythm of the week. Another is treating a resistant individual purely as a scheduling problem when it's actually a trust or incentive problem underneath. The more durable version of this doesn't depend permanently on one person's willpower to keep running it; if it collapses the moment its champion gets busy, it was never really a culture change.

Direct answer

Come in with a specific, narrow topic already chosen rather than opening with "any feedback for me," spend the first few minutes on one concrete recent example, and close by explicitly restating what you heard as an action, so both people leave agreeing on what changes in the next two weeks.

Structured elaboration

• Structure the fifteen minutes deliberately. Roughly two minutes to frame the specific topic and why now, eight to ten minutes on the actual discussion, and two to three minutes to explicitly summarize the action and confirm it. Fifteen minutes is too short for an open-ended "how am I doing," so the structure has to do the work of keeping the conversation focused.
• Choose one concrete recent example rather than asking about performance in general. "In yesterday's design review, did the way I pushed back on the proposal land the way I intended?" is answerable in the time available. "How am I doing overall?" is not.
• Ask questions that point at something changeable in two weeks, not a career-spanning trait. "What's one thing you'd do differently if you were in my seat this week?" or "Is there a pattern in the last couple of things I've done that I should watch for?" tend to produce a more actionable answer in a short conversation than "what's my biggest weakness?"
• Close by restating the action, not just the observation. "So the specific thing I'll change is X, and I'll check back with you on it in two weeks" turns a comment into a commitment both people remember, and gives a natural way to open the next conversation.
• The same structure works with a technical stakeholder reviewing a solution proposal, not just a manager. Narrow the ask to a specific part of the proposal, "does the failover approach in section two hold up, that's the piece I'm least sure about," and close the same way, by restating the concrete change you're going to make.

Worked example

Fifteen minutes with a manager: "I want to spend this on how I ran yesterday's incident, specifically whether I escalated at the right time." The manager says the escalation itself was fine, but the initial status update was too vague for people to know if it was urgent. The candidate restates: "so next time, I'll lead the status update with severity and impact before the details, I'll try that on the next incident and we can revisit." That's a concrete, two-week-actionable commitment, not a vague "I'll communicate better."

Trade-offs and pitfalls

Opening with "any feedback for me" in a fifteen-minute slot either produces a generic answer, or eats the whole meeting on the manager trying to think of something. Picking a topic too broad for the time available, "how's my career going," can't be resolved into a concrete two-week action. Not restating the action at the end leaves both people with a different sense of what was agreed. And using every single short check-in for this kind of narrow ask can crowd out other things the conversation needs to cover; save the technique for when a fast, actionable read is specifically what's needed.

Direct answer

Pick a specific missed milestone, own the real cause honestly rather than externalizing it, and lead with what concretely changed in how you set or pursued goals afterward, since that change is the actual answer to the question, not the miss itself.

Structured elaboration

• Choose a milestone specific and falsifiable. A promotion tied to a defined deliverable, not a vague "wanted to grow faster."
• Diagnose causation honestly. Was it a planning failure (underestimated scope or dependencies), an execution failure, or a criteria and timing failure outside your control? Don't default to blaming the organization if it was genuinely a planning miss, and don't over-blame yourself if it genuinely wasn't.
• Weight the structure toward what changed after, not the failure itself. Brief situation, the specific thing that went wrong, then spend real weight on the concrete behavior change afterward, a new habit, a changed way of scoping, a changed way of communicating risk.
• Tie the change to what you do differently now, not just what you did next that one time. That's what makes a "didn't hit it" story read as forward-looking rather than a confession.

Worked example

I once set a goal to reach a senior title within a year, tied to leading a specific migration project end to end. Partway through, I hit a dependency problem I hadn't scoped for, and it pushed the delivery out past the review window, so I didn't hit the milestone that cycle. What mattered wasn't the miss, it was that I went to my manager and named the planning gap directly rather than blaming the dependency, then changed how I scope big projects afterward: I now build an explicit dependency-risk review into the first week of any multi-quarter initiative, and I break milestones into smaller checkpoints so a slip shows up early rather than late. I got the promotion the following cycle, but more relevant to how I work now is that I still run that dependency review on every new initiative, missed milestone or not.

Trade-offs & pitfalls

• A story that ends at "and then I got promoted next cycle" without naming a durable behavior change reads as a lucky recovery, not growth.
• Externalizing the miss entirely onto the organization invites the follow-up "so what would you do differently," don't get caught without an answer.
• Over-owning a miss that was genuinely structural (a reorg, a frozen budget) reads as poor calibration in the other direction.
• Picking a trivial or vague "milestone" with no clear deliverable or date makes the whole story hard to evaluate.

Clarify goals & constraints

• Breakpoints should express component intent (compact / default / spacious) not just device widths.
• Single source of truth shared between Figma, tokens, and code.
• Support both viewport-based rules and container-query style component responsiveness.

Where breakpoints live

• Design tokens (Figma Tokens or FigJam): semantic names like card.size.compact / card.size.default / card.size.spacious with numeric width thresholds.
• CSS variables generated from tokens at build-time:
  --card-breakpoint-compact: 320px;
  --card-breakpoint-default: 600px;
  --card-breakpoint-spacious: 900px;
• Publish tokens in JSON, CSS, and JS packages so designers and devs consume the same values.

How developers consume them

• Viewport media queries (global):
  @media (min-width: var(--card-breakpoint-default)) { /* larger layout */ }
• Preferred: container queries for component-local adaptation:
  @container (min-width: var(--card-breakpoint-default)) { .Card { /* layout */ } }
• Utility classes / variants in component API:
  <Card size="compact">, or programmatic: <Card breakpoint="auto"> to let container queries decide.
• In Figma, use component variants named Compact / Default / Spacious linked to token values so mocks match implementation.

Nested components & composition

• Each component exposes its own semantic breakpoints (card.* vs card.header.*) derived from global token scale to avoid duplication.
• Use "collapse rules": child components inherit parent context when parent size < threshold (e.g., Card.Header switches to stacked layout when Card is compact).
• Implement with container queries: children query their closest container; if container-query unsupported, provide JS resize observer fallback.

Developer ergonomics & governance

• Export mixins and React hooks (useBreakpoint, useContainerQuery) so team uses consistent logic.
• Test cases: visual regression snapshots for each variant and nested scenarios.
• Accessibility: ensure breakpoint changes keep focus, readable type sizes and touch targets.

Trade-offs

• Container queries preferred for modularity but add polyfill complexity. Media queries simpler for global layout.
• Keep tokens semantic to allow design-led adjustments without touching implementation.

This approach aligns Figma, tokens, and code, enabling predictable, composable responsive cards across contexts.

Direct answer. An executive pitch for accessibility investment needs to lead with business rationale executives already care about, market size and legal risk being the two that translate most directly into numbers a finance-minded audience will act on, then follow with a phased, costed roadmap and a small set of metrics that will prove the investment worked.

Business rationale.

• Market size: roughly 15 percent of the world's population has some form of disability (WHO estimate); even a fraction of that share represents a meaningful addressable market a genuinely inaccessible product silently excludes.
• Legal risk: ADA Title III litigation in the US has targeted digital products with increasing frequency, and EN 301 549/the European Accessibility Act extend similar obligations across the EU; citing the organization's actual jurisdictional exposure is stronger than a generic "lawsuits happen" framing.
• User retention and brand: accessibility fixes frequently improve the experience for users without disabilities too (better contrast, clearer error messages, simpler navigation), so the investment isn't purely defensive.

Cost and phased roadmap. Present cost as a phased number, not one large ask: an initial audit and quick-wins phase at a bounded cost, followed by ongoing incremental investment (tooling, training, a dedicated role) sized against the existing accessibility debt found in that audit, so the ask is grounded in a real, current-state number rather than an abstract commitment.

Metrics to track ROI. A small set that's genuinely trackable: reduction in accessibility-related support tickets, reduction in critical/serious violation count over time, and, where measurable, conversion or task-completion-rate change for the affected user segment; avoid promising a large speculative revenue number that can't actually be attributed to the accessibility work specifically once other product changes ship in parallel.

Quantifying existing debt as part of the pitch. Open with the actual current-state number from a baseline audit (e.g. "142 critical and serious violations across our top 20 pages") rather than an abstract risk statement, since a concrete, already-measured number is far more persuasive to an executive audience than a hypothetical.

Trade-offs and pitfalls. Leading with a purely moral or compliance-fear argument, without the market-size and retention framing alongside it, tends to get accessibility treated as a cost center to be minimized rather than an investment with a return; leading with the business case first, and holding the legal-risk point in reserve rather than as the opener, generally lands better with a business-outcome-focused executive audience.