UX Designer interview questions

I would build an evidence-based inventory first, then decide what to consolidate rather than judging 180 components by visual similarity.

• Export Figma library analytics and search Storybook and the codebase, recording each component key, package, owner, 90-day usage, and consuming product in one audit sheet.
• Compare the three date pickers as interaction contracts: keyboard behavior, locale formats, range selection, validation, mobile behavior, and all 12 expected states, not just their screenshots.
• Deep-review the 30 most-used components and every component in 15 critical flows; inspecting all 180 equally would spend the 10 days on low-risk inventory instead of user-facing risk.
• Deliver a keep, merge, deprecate, or investigate decision for every item, with duplicate rate, orphan count, named owner, and target date in the audit report.

I would keep raw values in primitive tokens and expose semantic tokens as the stable contract used by every component.

• Store primitives such as blue.600, gray.950, and space.200 once; they provide the value palette but never appear directly in component styles.
• Map semantics such as surface.default, text.muted, and border.danger for each of the six brand-mode combinations, so a button consumes one name instead of six color branches.
• Add component aliases such as button.primary.background only when a shared semantic token cannot express a real component contract; that extra layer costs maintenance, so I would not create aliases for every property.
• Version the mappings in DTCG JSON and run contrast checks for all six themes in CI, failing a release when text pairs fall below the agreed WCAG AA threshold.

I would keep the seven-step flow as a product pattern unless a smaller, stable interaction contract can be extracted from it.

• Promote a component when it has one bounded purpose, reusable states, domain-neutral content, and at least three proven uses, such as the document-upload control shared inside those flows.
• Keep orchestration local when it contains verification policy, API sequencing, permissions, or recovery across seven steps; those rules belong to the product domain, not a generic component API.
• Pressure-test the proposed API in a Storybook spike: more than a handful of conditional flags or mutually exclusive props is evidence that the system is encoding several product workflows.
• Record the decision in a one-page boundary memo with owned component contracts, the local pattern recipe, non-goals, and the evidence that would trigger reconsideration.

I would make versioned DTCG JSON the canonical token source and generate both Figma mappings and platform outputs from the same commit.

• Give every token a stable ID and map it to a Figma collection, variable, and mode through the Variables API or an approved plugin, so renaming a label does not break the code link.
• Run Style Dictionary to emit CSS custom properties, TypeScript, iOS, and Android artifacts from one schema, with unit and dimension transforms owned in the token repository.
• In CI, reject missing references, circular aliases, invalid units, contrast failures, and unreviewed value deletions; Chromatic then checks representative components across all theme modes.
• Publish a semver token package and a matching Figma library update with the same release ID and changelog, accepting a short release lock to avoid designers and engineers consuming different versions.

I would release the new contract as a major version while keeping a measured compatibility window for the 12 consumers.

• Use code search and dependency reports to list every modal call site by team, critical flow, and unsupported prop, then assign each row an owner and migration week.
• Ship a codemod, before-and-after examples, and a temporary adapter for the common legacy API; the adapter costs one extra test path, so it expires after eight weeks.
• Canary the major version with two teams in week two, run keyboard, focus, visual, and consumer contract tests, then migrate the remaining teams in three weekly waves.
• Remove the old contract only when the board shows zero legacy imports across all 12 teams, rollback has been tested, and the sunset date has been announced in two release notes.

I would require the RFC to prove a shared table contract and expose the differences before anyone commits to an API.

• Include five real use cases, current workarounds, user impact, non-goals, and a decision on which sorting, selection, pagination, and bulk-action rules are genuinely shared.
• Attach anatomy, state and permission matrices, responsive behavior, content rules, and accessibility behavior for keyboard navigation, focus, headers, and screen-reader announcements.
• Provide a Figma prototype plus a Storybook code spike using realistic rows, empty states, 10,000-item pagination, and one failed bulk action rather than a polished happy path.
• End with proposed API, owners, package cost, rollout metrics, unresolved risks, and a five-day review window recorded in the RFC decision log.

I would move to federated contribution with risk-based review while keeping final release ownership in the four-person core team.

• Define three paths in a contribution handbook: documentation or token fixes, compatible component extensions, and new components, each with a different evidence and reviewer requirement.
• Route proposals through a GitHub template and promise triage within two working days; every extension gets one core reviewer and one product-domain reviewer instead of waiting for the whole council.
• Use CODEOWNERS, Storybook, accessibility tests, visual regression, and a release checklist as merge gates, so quality is enforced by artifacts rather than recurring approval meetings.
• Create a rotating contributor group from the 20 teams and require the originating team to support its addition for 90 days; this adds local maintenance work but prevents the core four from owning every edge case.

I would stop untracked copies immediately and make every necessary deviation visible, owned, and time-bounded.

• Store each exception in a versioned YAML registry with the component, product, unmet need, user evidence, owner, affected routes, fork location, approval date, and expiry date.
• Prefer a local wrapper around the supported package over copied source, because a wrapper preserves upstream security and accessibility fixes while a fork creates a second maintenance line.
• Give temporary deviations a 90-day review and require tests against the upstream contract; an expired record blocks the next release until it is renewed, migrated, or removed.
• Review the registry monthly and open a shared RFC when three exceptions cluster around the same need, while retaining separate forks when regulatory behavior is durable and explicitly funded.

I would report adoption as supported usage plus delivery and quality outcomes, not package installs or component count.

• Measure the share of eligible UI rendered from supported packages and linked Figma assets, split by critical flow and team; I would target 80% coverage before claiming broad adoption.
• Compare median design-to-production lead time for repeated patterns against the pre-launch baseline in Jira and Git, looking for a material reduction such as 12 days to 8.
• Track accessibility and visual-consistency defects per release, escaped component defects, and remediation time, because faster delivery that raises defects is not a system win.
• Add upgrade lag, active forks, expired exceptions, contribution lead time, and monthly active consumers to the dashboard so apparent coverage cannot hide stale or unsupported use.

I would run a staged migration with owned usage inventory, automated replacements, and a hard exit criterion at the end of the second quarter.

• In weeks one and two, map all 420 usages to teams, critical journeys, replacement readiness, and complexity, then publish a scorecard with one accountable owner per migration group.
• During the first quarter, block new legacy imports with ESLint, provide codemods and compatibility wrappers, and pilot two teams before moving the rest through four risk-based waves.
• Keep both libraries supported only through the migration window; parallel support doubles visual QA and release work, so wrappers and legacy fixes receive explicit sunset dates.
• In the second quarter, remove legacy Figma assets from publishing, verify zero runtime imports and critical-flow parity, rehearse rollback, then archive the package after all 16 owners sign the closure report.

I would make accessibility a release gate with automated checks, manual interaction tests, and an accountable exception path.

• In Storybook, every state must pass axe with no serious or critical violations, including error, disabled, selected, and high-contrast states.
• A reviewer tests the full date selection flow by keyboard and with NVDA plus Chrome, checking focus order, visible focus, labels, announcements, and escape behavior against WCAG 2.2 AA.
• The component contract includes 24 by 24 CSS pixel minimum targets or sufficient spacing, 4.5:1 text contrast, 3:1 control contrast, and no focus obscured by sticky content.
• The design-system accessibility owner signs the release; any exception names affected criteria, product risk, mitigation, owner, and an expiry within 30 days.

I would publish one behavioral contract that teams can verify across widths, content lengths, and all six supported locales.

• The Figma specification defines reflow at container widths of 320, 768, and 1440 pixels, flexible label and error regions, and no fixed height that clips wrapped copy.
• Storybook renders every state in en, ru, fr, de, pt, and es, plus a 50 percent text-expansion fixture and long dates, names, and decimal formats.
• The contract states truncation rules, minimum touch targets, label and error wrapping, control order, and which content may collapse below 320 pixels.
• CI captures the locale and viewport matrix, while the component owner blocks publishing if text overlaps, meaning is truncated, or focus order changes after reflow.

I would use one scored intake queue and publish the capacity decision for every request.

• Each request must name the user problem, affected products, evidence, current workaround, release deadline, accessibility or regulatory risk, and an engineering partner.
• A weekly 30-minute triage scores reach, severity, reuse across products, and cost of delay from 1 to 5, then subtracts estimated design and migration effort.
• For the quarter, I reserve 60 percent of capacity for the highest-scoring shared work, 25 percent for reviewed team contributions, and 15 percent for urgent accessibility or production defects.
• The public decision log shows accepted, delegated, needs-evidence, and declined requests with an owner and review date; requester seniority never changes the score.

I would separate contribution from publishing and give every library release one accountable owner.

• Only four design-system maintainers receive edit and publish access to the main library; product designers propose changes in branches linked to an intake ticket.
• A branch needs review from one design-system maintainer and the engineering component owner, with changed variants, tokens, accessibility behavior, and migration impact listed in the review.
• One maintainer acts as release owner, merges approved branches in a scheduled weekly window, publishes a named version, and writes the Figma release description and consumer migration note.
• Emergency publishes require a second maintainer, a linked incident, and a next-business-day review; quarterly access audits remove stale editor and publisher permissions.

I would make the Chromatic baseline deterministic, keep the pixel threshold strict, and require human approval for intentional changes.

• Critical components cover default, hover, focus, error, disabled, loading, and high-contrast states at 320, 768, and 1440 pixel viewports.
• I keep Chromatic's 0.063 diff threshold for normal stories and allow at most 0.1 only for a documented anti-aliasing case, never to hide layout movement.
• Any detected change in a critical state blocks the pull request until the design-system maintainer and component engineer accept the new baseline; unchanged stories need no manual review.
• Fonts, dates, animation, and test data are pinned in CI, and a monthly noise report removes flaky stories instead of repeatedly widening thresholds.

I would establish a single risk-based intake with a three-business-day triage SLA before promising study dates.

• The request form captures the pending decision, deadline, cost of being wrong, existing evidence, target participants, method assumption, and the person who will act on the result.
• Researchers score decision risk, reversibility, evidence gap, and recruiting difficulty in a weekly triage, then merge duplicate questions across squads.
• I allocate 70 percent of capacity to scheduled high-risk decisions, 20 percent to cross-squad strategic studies, and 10 percent to urgent issues; low-risk usability questions use templates and weekly office hours.
• The intake board shows accepted work, researcher, evidence date, redirected self-service work, and declined requests, with an escalation to the research lead when a decision cannot wait.

I would choose the repository through a scored pilot that proves retrieval, consent controls, and deletion before migrating all 500 studies.

• The scorecard weights security and privacy at 35 percent, findability and evidence provenance at 25, governance and permissions at 20, migration and export at 10, and three-year cost at 10.
• Vendors such as Dovetail and Condens must demonstrate SSO, role-based access, audit export, retention workflows, consent restrictions, regional hosting options, and a complete bulk export without proprietary lock-in.
• We pilot 50 studies spanning five years and three consent types, then ask 10 researchers and product partners to find evidence for real decisions and identify material they must not access.
• The Research Ops owner selects a tool only if restricted studies remain restricted, expired material can be deleted with proof, and 80 percent of pilot searches find usable evidence within three minutes.

I would manage the panel as a governed contact ledger with frequency caps, segment quotas, and visible fatigue signals.

• Every invitation and completed study is written to one panel record; users receive no new invitation for 90 days and join no more than two studies in any rolling six-month period.
• Sampling starts from decision-specific segment quotas, then randomly selects within eligible users instead of taking the fastest responders or the same power users.
• The intake check searches prior studies before recruitment, so a squad must show the unresolved evidence gap rather than repeat a question already answered in the repository.
• Research Ops monitors opt-outs, nonresponse, cancellations, and invitation volume by segment monthly, suppressing cohorts whose opt-out rate exceeds the panel baseline by 50 percent.

I would offer a 15-business-day recruiting SLA with explicit checkpoints rather than promise six administrators immediately.

• Research Ops confirms feasibility and finalizes a screener within two business days, including company size, admin permissions, recent task experience, conflicts, and quota limits.
• We recruit in parallel through consented customer lists from customer success, support and administrator communities, and one vetted B2B panel vendor, with a 150 to 250 dollar incentive based on seniority and market.
• The first two qualified profiles are due by business day 7 and all six sessions by day 15; if fewer than two qualify by day 5, the researcher and squad owner review scope and channels.
• The escalation options are extending to 20 business days, widening a documented noncritical criterion, or reducing the sample with narrower claims, never letting sales pressure customers to participate.

I would make the Research Ops data steward accountable for a consent-linked retention workflow, while each study researcher remains responsible for correct classification.

• At study setup, the researcher records consent scope, permitted audiences, recording status, withdrawal route, retention class, and deletion date in required Dovetail fields before uploading data.
• Direct identifiers and consent records stay in a restricted project; participant IDs replace names in notes, and raw recordings are deleted 30 days after analysis unless the consent and policy approve a longer period.
• A monthly expiry queue assigns deletion tasks, records who deleted each recording, transcript, export, and backup reference, and completes withdrawal requests within 30 calendar days.
• The data steward audits a 10 percent study sample quarterly for access, consent, retention, and deletion evidence, reports failures to Privacy, and keeps the immutable audit export for two years.