Senior UI Designer Interview Preparation Guide for Google

Situation & goal
As the UI Designer proposing a responsive layout + new CTAs, success = measurable lift in user engagement and business outcomes while maintaining UX quality across devices.

KPIs (primary + secondary)

• Primary: Conversion rate (CTA click → goal completion), Goal completion rate (sign-up, purchase).
• Secondary: CTA click-through rate (CTR), time-to-first-action, bounce rate, task success rate (usability), visual stability metrics (CLS).
• Qualitative: User feedback, usability test task completion, accessibility checks.

Segmentation

• By device: mobile portrait, mobile landscape, tablet, desktop.
• By platform/os: iOS vs Android vs Web.
• By user cohort: new vs returning, traffic source, screen resolution, high vs low network.
• Prioritize mobile-first if analytics show majority mobile traffic.

Experiment design (A/B)

• Two variants: Control (current) vs Treatment (redesign).
• Randomize at user-cookie or user-id level; persist assignment across sessions.
• Run parallel instrumentation for analytics and qualitative micro-surveys.
• Pre-register metrics and analysis plan; guard against peeking with sequential testing rules.

Sample size considerations

• Use baseline conversion p and desired minimum detectable effect (MDE) d.
• Rough sample size formula:

n = (Z_alpha/2^2 * p * (1 - p)) / d^2

• Choose alpha = 0.05, power 80% (Z values), inflate for segmentation and expected variance, and account for attrition. For low-conversion funnels, run longer or increase MDE.

Rollout criteria

• Rollout if: primary KPI lift is statistically significant, secondary metrics non-degrading, no major UX regressions, accessibility passed, and business stakeholders sign-off.
• Iterate if: marginal/no lift but improved qualitative feedback — run follow-up A/B variants (CTA copy, color, placement).
• Roll back if: negative impact on conversion, engagement, or accessibility.

Notes for execution

• Collaborate with PM/Analytics to instrument events; QA visual specs across breakpoints.
• Complement A/B with session replays and moderated usability on the treatment to explain why metrics moved.

Situation & Task
I designed a high-fidelity prototype with a complex microinteraction (animated card refresh) that PM called essential to “product feel.” Engineers pushed back citing CPU/GPU cost and jank on low-end devices. My task: mediate, test trade-offs, and reach a balanced decision.

Action

• Convened a 30‑minute alignment with PM and engineers; I summarized goals (emotion, clarity, perceived speed) and technical concerns to ensure shared understanding.
• Proposed measurable hypotheses: “interaction improves perceived responsiveness” and “budget must keep frame time <16ms on target devices.”
• Agreed on an experiment plan:
  • Build two lightweight prototypes: A = full animation; B = simplified animation (reduced layers, CSS transforms instead of heavy JS); C = no animation (baseline).
  • Run lab performance tests (Chrome FPS profiler, Lighthouse) and a 50-user remote moderated test measuring SUS-like perceived responsiveness and task completion time.
• Implemented quick animations in code sandbox with engineering help; captured metrics and short videos for stakeholders.

Result & Decision
Data showed A delivered best delight but exceeded 16ms on 20% of target devices and added 120KB of runtime cost; B hit performance targets and preserved ~80% of perceived benefit vs A. We decided to ship B with an opt-in progressive enhancement: enable full A on capable devices via feature-detection/UX flag. PM retained essential feel; engineers kept performance SLAs.

Learnings

• Translate subjective UX goals into measurable hypotheses.
• Use rapid, collaborative experiments to remove opinion from trade-offs.
• Deliver compromise with technical gating so the experience scales across devices.

Direct answer

A dedicated ideation phase exists to widen the option space before you commit build resources to any one direction. Prototyping tests a specific idea in enough fidelity to learn from; ideation generates the population of candidate ideas you choose that direction from. If you skip straight to prototyping, you are only ever testing the first plausible idea, not comparing it against anything.

Structured elaboration

Definitions

• Ideation: rapidly generating many candidate directions, in whatever medium is cheapest to produce and throw away.
• Prototyping: building a testable, sufficiently real version of one selected idea, to learn something a sketch cannot tell you (how it actually feels to use, whether it holds up under real data).

Why speed and quantity beat polish at this stage

• Cost of change: a sketch costs minutes to discard; a build costs days or weeks. Ideation deliberately stays in the cheap zone for as long as possible.
• Anchoring: a polished mockup signals false confidence and pulls reviewers toward evaluating the visual execution instead of the underlying idea.
• Coverage: generating more candidates raises the odds that a non-obvious, better direction is even in the room to be considered.

What you actually walk away with
Not a single deliverable, but a small set of genuinely distinct directions (not five variations on one idea), plus a record of what was considered and ruled out and why. That shortlist is what feeds the convergence step, where one or two directions get selected to prototype.

Common tools and when to reach for each

The analog-to-digital move matters for remote teams specifically: sketch fast on paper (it's still faster than a mouse for early divergence), then photograph or re-draw into the shared board so distributed participants can cluster and vote on equal footing.

Worked example

Given a brief to redesign a dashboard's data-summary card, a facilitator runs a fifteen-minute timeboxed round: each participant sketches three layout variants on paper (grid, list, hybrid) without discussion. Sketches are photographed into a shared Miro board so remote participants can see them alongside in-room ones. The group clusters similar sketches, discusses briefly, and picks one direction to carry into Figma for a clickable prototype. Nothing was built in Figma until a direction had already survived divergence and a first round of group discussion.

Trade-offs and pitfalls

• Skipping ideation and prototyping the first idea anchors the team early and means any later usability test is only ever confirming or denying one option, not comparing options.
• Running ideation with no convergence step afterward produces a pile of sketches and no decision; ideation needs to end in a shortlist, not just stop.
• Reaching for a high-fidelity tool too early (styled Figma components during divergence) tends to seduce the group into polishing one idea instead of generating several.

Why p‑values alone are misleading

A p‑value only tells you the probability of observing data at least as extreme as yours assuming the null is true. It doesn’t measure effect size, practical importance, or the probability the change is real. With small samples you can miss real effects; with huge samples you can “significantly” detect trivial differences. P‑hacking, multiple tests, and post‑hoc decisions inflate false positives.

Better practices to report

• Confidence intervals (CI): show range of plausible effect sizes and direction, e.g., “CTR increase 0.8% (95% CI 0.2%–1.4%)” — communicates precision and practical impact.
• Minimum Detectable Effect (MDE): set before the test so teams know the smallest business‑relevant lift we can reliably detect.
• Pre‑registration: lock hypotheses, primary metrics, sample size and analysis plan to prevent bias.
• Bayesian posterior intervals: give probability distributions over effect sizes (e.g., 90% probability lift > 0.2%), which is more intuitive for stakeholders.

How I’d operationalize this in the experiment playbook

• Template for experiment brief: required fields for hypothesis, primary/secondary metrics, MDE, sample size calc, and decision criteria.
• Dashboard output: always show point estimate + CI, p‑value, and MDE comparison; include a short plain‑English verdict (risk vs reward).
• Pre‑registration workflow in our tracking tool (link to Figma prototype for brief) and requirement to attach signed brief before launch.
• Training for PMs/designers: reading on interpreting CIs/Bayes, and playbook checklist gating launch/analysis.
• Post‑mortem step: record deviations, multiple comparisons, and business conclusion (not just “significant”).

This approach helps designers argue for changes using magnitude and uncertainty, not just “significant” badges — improving design decisions and stakeholder trust.

Short answer
Use expert heuristics when you need fast, low-cost, expert-driven coverage of obvious usability problems; use user testing when decisions affect real user behavior, accessibility, or high-risk flows and you need empirical evidence.

When to prefer heuristics (3+ criteria + thresholds)

• Tight timeline / limited budget — quick triage before release. Threshold: fix issues flagged by 2+ experts in a 3–5 person review.
• Low-risk or cosmetic decisions (visual polish, color contrasts within brand limits). Threshold: pass heuristic checklist and no expert flags > severity 2.
• Early-stage prototypes or many screens — find patterns quickly. Threshold: consolidate 80% of recurring UI issues across screens via heuristics before testing.
• Consistency & guideline checks (design system compliance). Threshold: 100% adherence for core components before user validation.

When to prefer user testing (3+ criteria + thresholds)

• Novel interactions, workflows, or conversion-critical flows (checkout, onboarding). Threshold: run moderated tests with 5–8 users for iteration; 15+ for quantitative confidence.
• Accessibility & edge cases (screen readers, motor impairments). Threshold: include representative users; meet WCAG success with real-user verification.
• Conflicting analytics or ambiguous behavior in production. Threshold: reproduce issue with user tests until task success differs >10% from expected.
• High business impact or risk (legal, safety). Threshold: empirical task success ≥90% for release.

Why
Heuristics catch obvious violations quickly using pattern knowledge; user tests reveal discoverability, mental models, and real-world mistakes. Combine both: run heuristics to prioritize, then validate high-impact items with users.

Direct answer

Don't remove the caveat, but respond fast with a concrete, shorter alternative rather than a flat no. Separate what's actually negotiable, wording, length, placement, from what isn't, the underlying risk the caveat describes, and say so out loud in the moment.

Structured elaboration

• Draw the line explicitly, right then: "I can't drop it entirely because it's a real constraint on what we can commit to, but I can make it tighter." That single sentence tells your colleague you're not being difficult, you're protecting something specific.
• Offer the rewrite immediately, not later. A fast, concrete alternative keeps you the collaborator in the room instead of the blocker; a flat "no, we need it" without an alternative invites exactly the pushback you're trying to avoid.
• If genuinely rushed, propose a placeholder now and a follow-up pass, rather than caving to get the slide out the door on time.
• Know when it's actually fine to cut. Ask: would removing this change what the executive decides or commits to? If the caveat is a hedge nobody will act on, trimming it is reasonable editing, not a compromise on accuracy. This case isn't that: the caveat describes a real performance limit that affects what can be promised.

Worked example

In the moment: "Thanks, I get wanting it to land cleanly for the execs. I can't remove that caveat entirely, it's a real constraint on what we can commit to, but I can reword it so it's short and exec-friendly. Want a one-line version that leads with the mitigation, or should we keep the technical detail in an appendix slide instead?"

Example transformation:

• Original (too technical): "Performance may degrade over 20% under sustained 10k concurrent writes without sharding."
• Executive-friendly (caveat preserved): "Under very high sustained write volume, throughput can drop, we mitigate this with sharding (splitting the data across multiple machines), and engineering will scope that work during the pilot."

Trade-offs & pitfalls

The failure mode in one direction is caving to a flat "just remove it" and letting a real risk disappear from the record, that's the version that comes back to bite the team when the limit gets hit in production and nobody remembers it was flagged. The failure mode in the other direction is treating every caveat as sacred and refusing to trim genuinely low-materiality hedges, which trains colleagues to see you as an obstacle rather than someone protecting the parts that matter. If your colleague pushes past a quick reword and asks you to cut something material, don't fight it out live in front of the deck, a quick "let's take five minutes offline before this goes out" resolves it without an audience.

Situation & goal
I’d design motion-aware accessibility so products respect user motion preferences while keeping interfaces informative and discoverable.

Detecting preferences

• Honor OS/browser settings (CSS media query prefers-reduced-motion) as primary signal.
• Provide an in-app toggle in Settings/Accessibility for granular control (Off / Reduce / Minimal).
• Persist preference per account and expose it in the design system tokens.

Alternatives for reduced motion

• Replace parallax/translate animations with cross-fades or instant state changes.
• Use reduced-motion variants: “Minimal” keeps duration <150ms and only opacity; “Reduce” disables non-essential movement.
• Provide user-controlled play-on-demand (e.g., “Show animation” button) and prefers-reduced-motion-aware microcopy.

Keeping components discoverable & informative

• Use motion-independent cues: color contrast, focus outlines, badges, and iconography to indicate state.
• Add live ARIA regions and status text for dynamic updates.
• Ensure timing and sequencing preserve semantic order; when motion is removed, animate-to-final state instantly but announce changes.
• Test with assistive tech and include examples in the design system with tokens, guidelines, and developer snippets.

This approach balances respect for user needs with consistent, accessible communication.

Direct answer
Ramping someone from day one to their first shipped work is a deliberate sequence, not a single onboarding checklist: assess what they actually already know, give them small real tasks with tight review loops before a full feature, gradually widen the scope of ownership, and define upfront what "shipped" and "done" mean so the finish line is unambiguous. The plan should look different depending on who's arriving, not just be a fixed template applied to everyone.

Structured elaboration

The default arc

• First few days: orient and assess. Don't assume a blank slate; find out what they already know so you're not re-teaching things or, worse, skipping things they actually need.
• Early tasks: small, real, low-blast-radius work with fast, close review. The goal here is confidence and calibration to the team's standards, not speed.
• Middle stretch: progressively larger scope with more independence, review shifting from "check everything" to "check the risky parts."
• First real shipped piece: something end-to-end they own, with you available but not doing it alongside them, and a clear definition of "done" agreed before they start, so success isn't a moving target.

Adapting the plan to who's actually arriving

This is where a generic checklist breaks down, and it's the part that separates a senior answer:

• A contractor under least-privilege or compliance constraints: access is scoped down from day one, so the plan has to work around what they legitimately can't see or touch, and documentation often needs to be more explicit since they can't casually ask around as easily as a full-time hire embedded in the org.
• A career-changer from an adjacent discipline (a backend engineer moving into data engineering, a research scientist moving into production ML): they're not a blank slate, they have real transferable skills. The plan should explicitly identify what carries over and target ramp-up specifically at the actual new-domain gaps, not restart from zero the way you would for someone with no relevant background.
• A cohort of remote interns rather than one hire: 1:1 pairing time doesn't scale to a group. The plan shifts toward a shared structured curriculum, peer learning between the interns, and scheduled office hours, with 1:1 time reserved for the things that genuinely need it.
• A remote hire versus a senior IC joining: a remote hire needs more of everything written down explicitly, since the informal hallway learning that fills gaps for an in-person hire doesn't happen by accident. A senior IC's gap is usually organizational context and relationships, not raw skill, so their plan should be lighter on procedural scaffolding and heavier on introductions, context on how decisions get made, and where the landmines are.

Worked example

Situation

I mentored someone joining as an individual contributor with solid general skills but no exposure to our specific stack or codebase, with a goal of them shipping one real, complete piece of work within their first several weeks.

Action

Week one was mostly orientation and a short assessment task to see where they actually stood, not a generic reading list. From there, I gave them a small real bug fix with a tight review loop so they got fast, specific feedback on our conventions early, before those habits calcified the wrong way. Over the following weeks the scope widened: a small self-contained feature with me reviewing closely, then a larger piece with me available but stepping back from line-by-line review, focusing instead on the riskiest parts of the design.

Result

They shipped a real, complete piece of work end-to-end within the target window, with a review pass that looked much closer to how we review any other team member's work by that point, which was the actual signal of readiness, not just that the calendar had passed.

Trade-offs & pitfalls

• Treating every new hire's plan as the same template. A junior mentor runs the same onboarding for a contractor, a career-changer, an intern cohort, and a senior IC. A senior mentor adapts the shape of the plan to who's actually arriving, because the actual gap being closed is different in each case.
• Under-scoping early tasks out of excessive caution, or over-scoping out of impatience. Both undermine the confidence-building purpose of the early stretch: too small and it's condescending or boring; too large too soon and the first review becomes overwhelming and demoralizing.
• Not defining "done" up front. Ambiguity about what counts as finished either causes needless rework or lets something ship that isn't actually ready, and both erode trust in the mentoring relationship.
• Ignoring the constraints a nontraditional hire is actually operating under. Applying a full-access, in-person, junior-IC plan to a least-privilege contractor or a remote hire sets them up to fail on logistics that have nothing to do with their actual skill.

Direct answer. WCAG has two target-size criteria at different levels, and they are not interchangeable: SC 2.5.8 Target Size (Minimum), added in WCAG 2.2, is Level AA and is the actual compliance floor most organizations are legally bound to (24x24 CSS pixels, with exceptions for inline targets, user-agent-controlled sizing, and targets spaced at least 24px from their neighbors). SC 2.5.5 Target Size (Enhanced) is the older, stricter Level AAA criterion at 44x44 CSS pixels with no spacing escape hatch. Platform guidance (Apple Human Interface Guidelines, Android Material Design) independently converges close to the AAA figure, roughly 44x44 CSS pixels, with at least 8px of spacing between adjacent targets, because fingertip contact area is meaningfully larger and less precise than a mouse pointer, and motor-impaired users need even more margin for error. In practice: treat 24x24 as the legal floor and 44x44 as the number you actually design to, since it is also what the platform guidelines independently recommend.

Why visual size and hit area can differ. A visually small icon (say 16x16px) can still meet the 44x44 requirement by having generous invisible padding around it that extends the clickable/tappable region without changing how large the icon looks, which is the standard technique for keeping a dense visual design while still passing the target-size requirement.

Documenting requirements for designers and developers. State the number as a hard floor in the design system ("44x44px minimum, 8px minimum spacing") attached to the interactive-component tokens, not as a general guideline in a separate document; specify it in both CSS pixel and physical measurement terms if the product spans web and native, since native platforms sometimes express the guidance in points/dp rather than raw pixels and a naive 1:1 translation across platforms can under-size the target.

Platform-specific notes. iOS Human Interface Guidelines recommend a minimum of 44x44pt; Android Material Design recommends 48x48dp; both are close to but not byte-identical to the WCAG 44x44 CSS-pixel figure, and a cross-platform design system should pick the stricter of the applicable platform guidance rather than the loosest.

Trade-offs and pitfalls. Density-focused designs (data tables with many small icon-only actions per row) are in real tension with this requirement; the usual resolution is a slightly taller row on touch/mobile breakpoints specifically, or converting inline icon actions into a single overflow "more actions" menu on small viewports rather than trying to fit six 44px targets in a row that was designed for a mouse.

Direct answer

I'd evaluate the request on three axes, reach (how many teams actually need this), fit (does the requested behavior still satisfy the design system's contracts around accessibility, theming, and the existing API's mental model), and cost (what maintaining a divergence costs the system long-term), and use those to route to one of three outcomes: extend the core Table if the need is broad and still fits the contract, grant a time-boxed exception if it's narrow and low-risk, or spin off a separate package if the performance or rendering model is fundamentally different from what the core Table was built to do. The default bias is toward keeping one accessible, well-tested Table implementation; a separate package is a real cost, not a free escape hatch.

Structured elaboration

Decision flow

flowchart TD
  A[Request: custom table behavior conflicts with system API] --> B{Common need across many teams?}
  B -- Yes, broad reach --> C{Still fits system's accessibility and theming contract?}
  B -- No, niche --> D[Exception: time-boxed and documented]
  C -- Yes --> E[Extend the core Table API]
  C -- No, different rendering model --> F[Separate package]
  D --> G[Review at expiry: retire or promote to extension]
  F --> H[Share design tokens and UX patterns]
  E --> I[Add tests, docs, versioned release]

Criteria

Why cost matters more than the first request looks

The tempting failure mode is treating "extend" as always the generous, collaborative answer. It isn't, if the requested behavior only serves one team and pulls the shared Table's API surface in a direction that makes it harder to reason about for everyone else, that's a cost paid by every future consumer, not just the requester. Conversely, refusing everything into "separate package" avoids core API bloat but risks fragmenting the product's table experience into several inconsistent widgets that all happen to be named Table.

Worked example

Concrete scenario: a team needs a table rendering 100k rows with custom cell virtualization and inline editing at 60fps-class responsiveness, and the core Table's DOM-based row virtualization can't hit that without a different rendering strategy (windowed canvas or a virtualization library with a different focus-management model).

Applying the criteria: reach is moderate (this team plus two others doing similar dense-data views), fit fails on the accessibility axis specifically because the performance approach requires bypassing the core Table's DOM-based focus and ARIA row model, not because anyone dislikes it. That combination (real reach, but a genuine structural fit failure) routes to separate package, not extend and not exception: extend would force the accessibility compromise onto every core Table consumer, and exception would leave three teams re-solving the same problem independently within a year. The separate package still imports the system's design tokens (spacing, typography, color) so it looks and feels like the same system, it just isn't the same component underneath, and its existence gets documented in the system's component index so the next team with a similar need finds it instead of building a fourth table.

Trade-offs & pitfalls

• Exceptions are the easiest option to grant and the easiest to regret: without an actual expiry date and a named owner for the review, "temporary" exceptions become permanent forks that nobody revisits, which is worse for the system's integrity than either a deliberate extension or a deliberate separate package.
• A separate package is not free just because it's not touching the core API: it still needs its own accessibility audit, its own token consumption discipline, and a place in the system's documentation, or it becomes exactly the kind of undocumented one-off the system was built to prevent.
• The failure mode on the "extend" side is API creep: each individually reasonable prop addition is easy to approve, but a Table that's accumulated a dozen conditional behaviors to satisfy every past exception request becomes hard for anyone to reason about, which is its own maintenance cost that rarely gets attributed back to the decisions that caused it.
• A senior answer names the re-evaluation trigger up front (a separate package that gains enough adoption should periodically be reconsidered for promotion into the core system, and an exception that's still active a year later is a signal the criteria were applied wrong the first time), rather than treating the decision as made once and never revisited.