Mid-Level UI Designer Interview Preparation Guide - FAANG Standards

Situation / Goal
As a UI Designer I’d specify instrumentation so product and analytics can tie clicks on a new CTA to downstream outcomes while keeping names clear for engineers.

Event naming & conventions

• Event name: cta_click
• Namespace pattern: component_action (lower_snake_case). Example: header_signup_cta_click or pricing_upgrade_cta_click
• If multiple CTAs same visual: include variant: pricing_upgrade_cta_click_v2

Minimum properties to capture

• page: string (e.g., "/pricing")
• component: string (e.g., "pricing_upgrade_cta")
• cta_text: string (visible label)
• cta_variant: string (primary/secondary/v2)
• interaction_type: string (click/tap/keyboard)
• element_position: string (header, hero, footer)
• user_id: string or null (for logged-in users)
• session_id / client_ts: timestamp
• viewport: width x height or breakpoint (mobile/desktop)

Why: these let analysts join to sessions, A/B variants, and attribute conversions.

QA steps (desktop & mobile)

• Dev console: click CTA and verify event fires with correct properties in Network/analytics request.
• Use analytics debug mode (e.g., GA4 DebugView / Segment debug) to inspect payloads.
• Keyboard test: Tab→Enter to confirm interaction_type = keyboard.
• Mobile: test responsive breakpoints and a real device (tap) and emulator; confirm viewport value and same event name.
• Edge cases: anonymized users, long labels, and dynamic text/disabled states.

Direct answer

Do not treat the metric win and the UX risk as opposing bets. Before building anything, agree with design and product on the primary success metric and on explicit guardrail metrics chosen specifically to catch the kind of harm the primary metric would not see, then validate cheaply with a prototype or a small qualitative test before committing to a live experiment sized to detect both.

Structured elaboration

Agree on what "good" means before anyone builds

The primary metric, say a conversion or engagement number, tells you if the change works on its own terms. Guardrail metrics are chosen specifically because they would catch harm the primary metric is blind to, such as task completion, return usage a week later, or support-ticket volume. Naming guardrails upfront, with agreed thresholds, prevents "we'll know it if we see it" arguments after the fact.

Validate cheaply before going live

A clickable prototype or a small moderated usability session can surface confusion or trust issues that the metric alone cannot catch, at a fraction of the cost of a live experiment. This is not a substitute for the experiment, it is a cheap filter that catches the worst ideas before they reach real users.

Run a bounded experiment, not a full rollout

Start with a small slice of traffic, watch both the primary metric and the guardrails, and decide the stopping rule, meaning what result on which metric ends the test, before the test starts, not after you see the numbers.

Decide and communicate together

If the primary metric improves but a guardrail moves the wrong way, that is a real finding, not a technicality to explain away. Whether to ship, iterate, or drop the idea is a joint call between design, product, and whoever owns the guardrail metric, made against the thresholds agreed upfront.

Worked example

Design proposes reordering a list of recommended items to increase click-through rate. The concern is that users may have learned to expect a stable, predictable order, and reordering it could hurt their ability to quickly find what they are looking for on repeat visits, something click-through rate would not show because a user can click more and still be more frustrated.

Before building, the group agrees the primary metric is click-through rate, and the guardrails are task completion rate (did the user's search end in the outcome they were after) and a return-usage check at one week out. A moderated usability test with a handful of participants on a clickable prototype surfaces that new users find the reordered list fine, but a couple of returning participants mention it "looks different" and take longer to find what they normally click first. That is a signal, not a stop sign: the team ships the change to a small slice of traffic, watches both metrics for an agreed window, and only expands the rollout if task completion holds steady alongside the click-through gain.

Trade-offs and pitfalls

Over-instrumenting every change with a full guardrail suite slows teams down and trains people to skip the process for anything that feels small. Guardrails should be chosen deliberately for the specific risk in question, not applied as a blanket checklist.

The sharpest failure mode is agreeing on guardrails in principle but not on thresholds, so when a guardrail moves slightly, the debate about whether it is a real regression happens after the data is already in and someone has already committed emotionally to shipping. Fixing the threshold before the test removes that fight.

Direct answer

Build the Button as a polymorphic, ref-forwarding component: a typed as prop lets consumers render it as any element - most commonly a link - without a second component, forwardRef exposes the real underlying DOM node, and accessibility is handled by defaulting to a native <button> and only adding ARIA/keyboard shims when as overrides that default.

Structured elaboration

Approach

• Prop shape: variant, size, disabled, onClick, children, an as prop for polymorphism, plus pass-through for whatever native props the resolved element supports, via TypeScript's ComponentPropsWithoutRef<E>.
• Polymorphism: as swaps the rendered tag. At the type level this uses a generic <E extends ElementType> so both the prop types and the ref type change correctly per element - as="a" should require href to type-check and forward a ref typed as HTMLAnchorElement, not HTMLButtonElement.
• Ref forwarding: forwardRef passes a ref straight to the rendered host element so a parent can call .focus() or measure it, with no imperative API of the component's own needed.
• Accessibility: default as to "button" (native semantics, native keyboard support, native disabled behavior - nothing extra to add). Only when as is a non-button element does the component need to add role="button", tabIndex, Enter/Space keydown handling, and aria-disabled (non-form elements don't support the native disabled attribute).

Worked example

import React, { ElementType, forwardRef, ComponentPropsWithoutRef, Ref } from "react";

type Variant = "primary" | "secondary" | "ghost";
type Size = "sm" | "md" | "lg";

type PolymorphicProps<E extends ElementType> = {
  as?: E;
  variant?: Variant;
  size?: Size;
  disabled?: boolean;
  children?: React.ReactNode;
  "aria-label"?: string;
} & Omit<ComponentPropsWithoutRef<E>, "as" | "children" | "disabled">;

function ButtonInner<E extends ElementType = "button">(
  { as, variant = "primary", size = "md", disabled = false, children, onClick, onKeyDown, ...rest }: PolymorphicProps<E>,
  ref: Ref<Element>
) {
  const Component = (as ?? "button") as ElementType;
  const isNativeButton = Component === "button";

  const handleClick = (e: React.MouseEvent) => {
    if (disabled) { e.preventDefault(); return; }
    (onClick as React.MouseEventHandler | undefined)?.(e);
  };

  const handleKeyDown = (e: React.KeyboardEvent) => {
    if (!isNativeButton && !disabled && (e.key === "Enter" || e.key === " ")) {
      e.preventDefault();
      (onClick as React.MouseEventHandler | undefined)?.(e as unknown as React.MouseEvent);
    }
    (onKeyDown as React.KeyboardEventHandler | undefined)?.(e);
  };

  return (
    <Component
      ref={ref}
      className={`btn btn--${variant} btn--${size}`}
      onClick={handleClick}
      onKeyDown={handleKeyDown}
      {...(isNativeButton ? { disabled } : { role: "button", tabIndex: disabled ? -1 : 0, "aria-disabled": disabled || undefined })}
      {...rest}
    >
      {children}
    </Component>
  );
}

export const Button = forwardRef(ButtonInner) as <E extends ElementType = "button">(
  props: PolymorphicProps<E> & { ref?: Ref<Element> }
) => React.ReactElement | null;

Key points

• PolymorphicProps<E> derives the correct native prop set per element from ComponentPropsWithoutRef<E>, so as="a" correctly types href and as="button" correctly types type.
• Native disabled is applied only to the real <button>; non-button elements get aria-disabled plus a click-time guard instead, since HTML has no disabled attribute for <a>.
• Keyboard support (Enter/Space triggers click) is added only when the rendered element isn't already keyboard-activatable natively.

Complexity
This is a UI component, not an algorithm, so the relevant complexity is structural rather than asymptotic - rendering, prop-forwarding, and event handling are all O(1) relative to the component's own props, with no loop or recursion over data. The real cost worth naming is at the type level: the generic PolymorphicProps<E> and the forwardRef cast add genuine TypeScript compile-time complexity and a learning curve for contributors unfamiliar with the polymorphic pattern - a maintenance cost, not a runtime one.

Edge cases

• as="a" with no href: renders a link with no navigation target and no visible affordance change - worth a dev-time warning rather than shipping silently.
• Icon-only usage with no visible children text: requires aria-label from the consumer; the component should warn in development if neither text children nor aria-label is present.
• disabled combined with as set to a non-interactive element (e.g. as="div"): must still block both click and keyboard activation, which is why the guard lives in the shared handlers rather than relying on the native disabled attribute alone.
• Ref type mismatch: a consumer typing useRef<HTMLButtonElement>(null) while also passing as="a" gets a type conflict at the call site by design - that's the polymorphic typing working as intended, not a bug to suppress.

Trade-offs & pitfalls

• The polymorphic as pattern is powerful, but the TypeScript required to type it correctly (generic ref forwarding, conditional prop types) is genuinely more complex than a fixed-element component. For a small design system with few link-as-button use cases, two simple components (Button, LinkButton) sharing internal styling logic can be more maintainable than one fully polymorphic component.
• The common wrong turn is forwarding disabled straight into {...rest} for every element type. On a non-button element this silently does nothing (no native support), giving a false sense that the element is disabled when it's still clickable and focusable.
• A second common wrong turn is skipping the keyboard handler because it "looks fine visually." A role="button" div without Enter/Space handling passes a casual visual check but fails immediately for keyboard-only and screen-reader users.

Direct answer

Problem statement: "Users abandon the checkout flow at a rate we believe is avoidable, driven by unclear pricing or an overly long form; we want to identify the dominant cause and reduce abandonment within one quarter." Then three research questions, ranked by how much uncertainty each removes, and two experiments that test the two most likely causes cheaply before committing to a redesign.

Structured elaboration

Turning "make checkout less confusing" into something actionable means resisting the urge to start sketching a new flow and instead doing three things in order:

1. State the problem without naming the fix. "Confusing" is a symptom description from whoever gave you the brief, not a diagnosis. The statement should capture the business impact (checkout abandonment, cart-to-purchase drop-off) without assuming the cause is visual clutter, form length, or anything else specific.
2. Rank the highest-uncertainty questions. Three that reduce the most uncertainty for the least effort: (a) where in the funnel do users actually drop, step by step, not just "checkout" as a whole; (b) do session recordings or support tickets show a specific point of friction (an unexpected shipping cost, a validation error, a confusing field); (c) has anything changed recently (a redesign, a new payment provider, a pricing change) that correlates with the drop, which would point to a regression rather than a long-standing usability gap.
3. Design experiments that isolate one variable each. Confirming the top hypothesis before building the full redesign avoids spending a sprint on the wrong fix.

Worked example

If step-by-step funnel data (question 1) shows the drop concentrates at the shipping-cost step, and session recordings (question 2) show users repeatedly navigating back to the cart after seeing that price, the two experiments become: (1) show an estimated shipping cost earlier in the flow, on the cart page, and measure the change in step-to-step conversion at the shipping step specifically; (2) offer a lower-friction guest checkout for users who abandon at account creation, and measure whether abandonment at that specific step drops. Both experiments have one clearly measurable outcome each (conversion rate at a named step) rather than "conversion is better," which would leave you unable to tell which change caused any improvement.

The same three-part output, statement, research questions, experiments, holds regardless of who the ambiguous brief comes from: an engineering-reported inconsistency (three teams shipping visibly different versions of the same navigation component), a chief executive officer (CEO)-level ambiguous goal ("increase monetization from casual users," with no design specifics attached), and a product manager's (PM's) "improve discoverability" ask with no defined success metric all reduce to the identical framing move, only the domain changes.

Trade-offs and pitfalls

The trap in this kind of prompt is treating "less confusing" as license to redesign everything at once: a full redesign conflates multiple hypotheses, so even if overall conversion improves you cannot attribute the gain to any one change, and if it does not improve you have no idea which piece to revert. The second trap is skipping the funnel-breakdown question entirely and going straight to user interviews, which surface real but not necessarily representative friction points; pairing quantitative funnel data with qualitative signal is what keeps the research questions honest about what's actually costing conversion versus what's merely annoying.

Approach / model

• Model the checkout as explicit states: Idle → Filled → AddressValidationPending → PaymentProcessing → {PaymentFailed, PaymentSucceeded} → OrderConfirmation.
• Define events: INPUT_CHANGED, SUBMIT_ADDRESS, ADDRESS_VALIDATED_SUCCESS, ADDRESS_VALIDATED_FAIL, START_PAYMENT, PAYMENT_SUCCESS, PAYMENT_FAIL, RETRY.
• Include guards (e.g., form valid) and entry/exit actions (show loader, disable inputs, show toast).

Tooling & documentation

• Draw a visual state diagram in FigJam for stakeholder alignment (states, events, transitions, guards).
• In Figma create a component set where each state is a variant of the Checkout component (visual differences: disabled inputs, spinners, inline errors, success screen). Use Auto Layout and component props for consistency.
• Build interactive prototype in Figma/Framer/ProtoPie using timed transitions and event triggers; for dev handoff attach the FigJam state machine plus a simplified XState JSON snippet to show intended behavior. Use Storybook for component-level interactive examples and visual regression.

Testing transitions & recovery

• Simulate async with mocked network in prototype: provide fast/slow/failed responses to exercise loaders and timeouts.
• Write an interaction test matrix (happy path, validation fail, network timeout, payment decline, retry flow). For each, note expected visual cues, focus management, and ARIA alerts.
• Run moderated usability sessions focusing on error comprehension and recovery; capture where users get stuck.
• For dev QA, provide Storybook stories and automated Playwright/Cypress tests that trigger events and assert DOM states (spinner visible, retry button enabled, order id shown).

Why this fits a UI Designer

• Visual state mapping ensures consistent UI across async flows; component variants speed prototyping and handoff; testing matrix ties visual cues to user outcomes so design decisions are validated.

Direct answer

Pick a project you chose deliberately because it filled a specific, named gap in your experience or visibility, not just one that landed on your desk, and be concrete about the one thing that measurably changed in your trajectory afterward, a capability, a relationship, or a type of work you're now trusted with.

Structured elaboration

• Name the specific gap the project targeted. A skill, a type of stakeholder exposure, a kind of ownership, not "it seemed interesting."
• Distinguish accelerant projects from ordinary assigned work. You sought it out or volunteered specifically because of the gap; that intentionality is the actual signal being tested.
• Point to something durable in the "what changed" half. A new kind of work you're now trusted with, a relationship that opened later opportunities, or a capability you now use routinely, versus just "it went well."
• Keep it forward-looking. The project itself is evidence; the answer is really about what it changed about how you're used or seen now.

Worked example

Partway into a role, I noticed a gap in my own experience: I'd never owned something end to end in front of a skeptical stakeholder audience, only ever as part of a larger team. When a short, high-visibility project came up that nobody else wanted because of the tight timeline, I volunteered specifically because it forced that gap. I ran it end to end, made the calls, and presented the outcome directly to the stakeholders who'd been skeptical going in. What actually changed afterward wasn't the project's result, it was that I started getting pulled into that kind of stakeholder-facing, ambiguous work as a matter of course, work I'd never have been offered before proving I could carry it alone.

Trade-offs & pitfalls

• Choosing a project purely because it's visible, without it targeting a real gap, produces a story about luck rather than intentional growth.
• Framing the outcome as "and it went well" rather than naming what changed afterward misses the actual question, the interviewer wants the trajectory change, not the project recap.
• Volunteering for something without being honest about the real risk, a tight timeline, being out of your depth, undersells the growth; own the discomfort as part of the story.

Direct answer. Three concrete accessibility features for a BI dashboard used by visually impaired or color-blind teammates: keyboard-navigable filters and charts (so the dashboard is usable without a mouse), redundant non-color encoding on every chart and status indicator (so meaning survives for color-blind users), and a genuine accessible-alternative data table for every chart (so a screen reader user gets the same information a sighted user reads visually).

Feature 1: keyboard-navigable filters and interactive charts. In Tableau or Power BI, this means ensuring every filter control, parameter, and interactive chart element is reachable and operable via keyboard, which in practice depends heavily on how the dashboard was built within the tool (custom web-object embeds behave differently from the tool's native filter controls) and needs to be verified directly rather than assumed, since BI-tool accessibility support varies meaningfully by which specific feature/control type is used.

Feature 2: redundant non-color encoding. Status indicators (on-track/at-risk/off-track) get an icon or text label alongside the color, not color alone, matching the general redundant-encoding discipline used for any color-coded status indicator; both Tableau and Power BI support adding data labels and icon-based conditional formatting on top of color-coded visuals specifically for this purpose.

Feature 3: accessible alternative data table. Both tools support an underlying "view as table" or "summarize as table" option that exposes the same data a chart visualizes in a genuinely screen-reader-navigable tabular format; enabling and testing this specifically (not assuming it's automatically wired up correctly by default) is the concrete implementation step, since some chart types' default table-view export doesn't include every visually-encoded dimension without additional configuration.

How to implement and validate each. For keyboard navigation: an actual keyboard-only walkthrough of the published dashboard, not just the design/edit view, since published-dashboard interaction behavior can differ from the editing experience; for redundant encoding: a color-vision-deficiency simulation tool (built into some BI platforms, or an external one) applied to the published dashboard; for the data-table alternative: confirm with an actual screen reader that the table view announces column headers and values correctly, not just that the toggle exists.

Trade-offs and pitfalls. BI-tool accessibility support is genuinely uneven across the tool's own feature surface, a native filter control may be fully keyboard-accessible while a custom-embedded web object in the same dashboard is not, so validating each specific tool feature actually used, rather than trusting a general "the platform is accessible" claim, is what catches the real gaps.

Direct answer

Teaching a skill you don't have natural talent for means separating what you know intuitively from what's actually teachable. You diagnose the real gap first, build an explicit, decomposed framework for the skill (even though you perform it by feel), and validate progress by watching the person apply it independently, not by how confident the coaching sessions felt.

Approach to teaching outside your natural strength

Diagnose before prescribing. "Struggles with X" is rarely one problem. Watch or review their actual attempt and separate the layers: is it a knowledge gap (they don't know the structure), a delivery gap (they know the structure but execution is shaky), or a confidence gap (they know it and can do it, but freeze under real stakes). Each needs a different intervention.

Decompose your own tacit skill into explicit steps. If you're good at something without having consciously learned it as a framework, you have to reverse-engineer your own process before you can teach it. Skipping this step and just saying "do what feels right" doesn't transfer anything.

Practice at graduated, increasing stakes. Start with low-stakes reps where mistakes are cheap and recoverable, then move toward the real, higher-stakes version. Jumping straight to the real thing conflates skill-building with performance evaluation in the person's head, which raises anxiety and slows learning.

Give feedback on the mechanism, not just the outcome. "That worked" or "that didn't work" is much less useful than pointing at which specific move in their approach caused the result.

Worked example

Situation: someone you're mentoring is excellent at the core technical work but has a real gap in a skill that doesn't come naturally to you either, say, communicating findings clearly to people outside the immediate team. Their material was always technically sound, but reviews ran long and the point often got lost.

Task: help them close that gap over a defined stretch, without pretending you have natural talent for it yourself.

Action: you watched a recording of one of their sessions together and separated content problems (no clear headline, too much detail up front) from delivery problems (pace, not anticipating pushback). You gave them a simple structure to practice against: state the conclusion first, then the supporting evidence, then the recommendation. You ran a couple of low-stakes rehearsals where you played a skeptical stakeholder, then let them run the real session solo.

Result: over a few sessions, their reviews needed fewer clarifying follow-up questions from the room, and the structure started showing up unprompted in written material too, not just live presentations. The real signal wasn't how the coaching sessions felt: it was watching them handle a session you weren't part of and hearing secondhand that it landed cleanly.

Trade-offs and pitfalls

A common junior-mentor mistake is trying to transfer your own tacit competence directly ("just do what I do") instead of decomposing it. That fails specifically because the skill you're teaching is one you never consciously learned as steps.

Another mistake: avoiding coaching on gaps you don't personally excel at, on the theory you're not qualified. You don't need to be naturally gifted at a skill to teach its structure. You need to be willing to build the explicit framework, which sometimes non-naturals do better than naturals, because they had to learn it deliberately themselves.

The real trade-off is time. Teaching a skill outside your own strength takes longer to prepare for, because you can't rely on instinct in the room. That prep time is where the actual coaching value gets built.

Overview / Purpose
One-line summary of the component and when to use it — helps designers and devs quickly decide if it matches their need.

Anatomy / Visuals
Rendered examples (states, sizes, breakpoints) and labelled parts (icon, label, container). Shows visual behavior and spacing rules designers care about.

Props / Tokens / Variants
List of props with types/acceptable values, default values, and mapping to design tokens (colors, spacing, typography). Enables consistent implementation.

Interactions & States
Keyboard behavior, hover/focus/active/disabled/error states, motion specs — ensures accessible, predictable interaction.

Usage Examples / Recipes
Code snippets + Figma links for common use cases (inline, modal, list). Practical patterns speed adoption.

Accessibility Notes
WCAG expectations, ARIA roles, and known limitations — critical for compliance.

Design Tokens & Specs
Token names, CSS variables, token values, and downloadable assets (SVGs, icons).

Do’s & Don’ts
Clear visual examples of correct and incorrect usage to prevent common mistakes.

Related Components & Migration
Links to components to combine with and notes on deprecated alternatives.

Changelog & Versioning
Notes on breaking changes, release, and who to contact for design clarifications.

Answer (UI Designer perspective)

Overview & tokens
I define semantic tokens for both modes: color.primary, color.onPrimary, color.background, color.surface, color.success, color.error, color.warning. Each token maps to a role (interaction, text on role, container) instead of specific hexes so developers and designers can swap palettes without breaking semantics.

Deriving dark-mode values

• Preserve hue; transform Lightness/Chroma in a perceptual space (OKLab or Lab/Material HCT). Reduce lightness for backgrounds, increase for “on” colors so text stays readable; reduce chroma for high-saturation colors in dark to avoid glow.
• Use a tone-mapping curve: tone_dark = clamp( 100 - f(tone_light) , 0, 100 ) where f is tuned per token class (e.g., backgrounds invert more, accents invert less).
• Generate tonal palette programmatically (design-tool plugin or script) and pick tones for primary/onPrimary that maintain contrast.

Testing & validation

• Automated checks: compute relative luminance and WCAG contrast ratios (normal text 4.5:1, large text 3:1, UI components/graphics ≥3:1). Fail CI if any token-pair falls below threshold.
• Visual tests: Storybook stories for each token pair in light/dark, with component states and overlays; snapshot + manual review for perceived contrast and glow.
• Tools: Axe / pa11y for pages, contrast-ratio CLI, Chromatic for visual regressions, Figma plugin to preview tokens in both themes.
• Edge cases: layered surfaces, alpha blend with elevation tints — test composite contrast by compositing tokens over surfaces programmatically.

Outcome
This approach yields consistent, accessible semantic tokens where dark values are derived predictably and validated automatically and visually.