UX/UI Designer interview questions

I treat product vision as the business destination and UX vision as the future experience that makes it credible.

• Product vision defines the customer, value proposition, and market position; UX vision translates those choices into an experience promise.
• UX vision should guide journeys and channels, not prescribe screens in Figma.
• Every experience principle should advance a product bet and a recognizable user outcome.

I build an explicit chain from the business goal to user value, observable behavior, and the design intent supporting it.

• Retention may mean completing recurring work with fewer errors, repeated steps, and recovery actions, not merely returning more often.
• Design intent states what the experience enables, while metrics show whether it happens at acceptable quality.
• Commercial measures need guardrails such as errors, opt-outs, and accessibility failures so growth cannot hide harm.

A useful North Star captures repeated delivery of core user value, but one aggregate always needs quality guardrails.

• I choose behavior close to value received, such as completed collaborative workflows, rather than visits or clicks.
• The unit, eligible population, and window must be precise enough to prevent counting artifacts.
• Guardrails cover failure, equitable access, trust, and viability through errors, differences between segments, opt-outs, or support cost.

A durable principle expresses a distinctive choice and the trade-off it resolves, not a slogan such as simple or intuitive.

• It should trace to evidence and strategy, such as favoring reversible exploration over forced setup.
• It needs a counterexample so a proposal can clearly violate it.
• It should survive individual features but have a review trigger when the product model changes.

An opportunity roadmap sequences outcomes and unresolved problems, while a solution roadmap commits to features.

• Opportunities preserve several solution paths and expose assumptions when evidence is incomplete.
• Solutions belong in delivery once value and feasibility have enough support; endless discovery is not strategy.
• Each opportunity needs evidence, an outcome signal, and a decision date to avoid becoming a wish list.

I separate near-term repairs, medium-term capability bets, and long-term options because each needs different evidence and commitment.

• The near horizon uses known constraints; the middle validates behavior and operating assumptions.
• The far horizon is a portfolio of hypotheses in concepts or Framer prototypes, not promised UI.
• Dependencies matter so urgent fixes do not harden architecture that blocks the intended future experience.

I optimize for reducing the most consequential uncertainty, not polishing a comprehensive interface.

• I separate desirability, usability, feasibility, and viability because a ProtoPie prototype answers only some of them.
• Interviews and concept tests find language and behavior, then real commitment matters more than stated enthusiasm.
• The design stays reversible until the core object model and value exchange survive actual use.

A service blueprint makes strategy concrete by exposing the channels, actors, policies, and backstage capabilities behind the promise.

• Journey stages show user outcomes, while backstage lanes reveal failures that screens cannot fix.
• The ecosystem view identifies value exchanges and dependencies across support, partners, and operations.
• I use it to sequence capability investments and mark assumptions, not as evidence by itself.

I would use a four-layer token graph: primitives, semantics, components, and platform outputs, with brand and theme expressed as modes rather than forks.

• DTCG JSON would hold neutral primitives such as color.blue.600 and an 8-point spacing scale; product code could not reference that layer directly, which costs one extra alias lookup but prevents brand values leaking into components.
• Semantic tokens such as surface.default and text.danger would resolve through 4 brand-theme mode sets, so 2 brands times 2 themes remain one contract instead of 4 copied libraries.
• Component tokens would exist only for real exceptions, for example button.primary.background; I would cap them through a quarterly Token Taxonomy Matrix review because 300 component aliases can become harder to govern than 40 semantic ones.

I would make reviewed DTCG JSON the release source and treat Figma Variables, platform packages, and Storybook as generated consumers.

• A schema check would validate names, types, aliases, and 4 brand-theme modes on every change; direct edits to published Figma collections would be overwritten, which limits spontaneity but removes bidirectional merge ambiguity.
• Style Dictionary would build CSS, Swift, and Android artifacts from the same commit, then the Figma Variables API would update mapped variable IDs rather than create new ones on each run.
• The Token Provenance Manifest would record each DTCG path, Figma variable ID, package version, source checksum, and Storybook build URL, making a mismatched value traceable in under 5 minutes.

I would use tiered contribution paths and distribute evidence and implementation work while keeping contract approval with the core team.

• The Contribution RFC would require 2 product examples, the unresolved user need, states, accessibility evidence, an engineering owner, and expected reuse; a typo fix skips this path, while a new component does not.
• A rotating maintainer acknowledges each request within 2 business days and routes it to fast fix, extension, experimental pattern, or reject, reserving full review for public API changes.
• The RFC records a decision owner and deadline within 5 business days; overdue items escalate to the system owner, while stable and experimental components retain different approval and adoption thresholds.

I would publish a new major with a temporary compatibility layer, then migrate the 9 applications in measured waves rather than changing them all at once.

• Version 2.8 would add deprecation warnings, while 3.0 introduces the new FormField contract plus a temporary adapter for legacy props; carrying both paths for 6 weeks costs bundle size but keeps each app independently deployable.
• A jscodeshift codemod and migration guide would target the mechanical 80 percent, leaving each app's 2 engineer-days for validation logic and visual review rather than prop renaming.
• The Six-Week Migration Ledger would name the owner, current version, codemod result, contract-test status, and release date for all 9 apps, scheduled in waves of 2, 3, and 4 consumers.

I would share the stable interaction primitives and keep the 5-step workflow state machine inside each product until its domain contract is genuinely common.

• The design system would own Stepper, FormSection, ValidationSummary, save-and-resume shell, and accessibility behavior, each documented in Storybook with states rather than merchant rules.
• Each product would own its XState machine, API calls, eligibility branches, copy, and analytics events; centralizing those 5 steps now would couple one release to 3 different domain owners.
• The Boundary Decision Record would map ownership and dependencies for every layer, including a rule that product code may compose shared components but the design-system package may not import product schemas.

I would make every approved deviation a traceable, expiring contract linked to the exact design and code surfaces it changes.

• Each Deviation Register entry would include an ID, regulation citation, jurisdiction, affected token or component, rationale, risk, owner, approvers, introduction date, review date, and 7-year evidence link.
• Status would move through proposed, approved, expiring, remediated, or rejected, with Legal and the design-system owner both required for approval and automated reminders 30 days before review.
• The same deviation ID would appear in a Figma annotation and a dedicated Storybook story, so an auditor can move from rule FIN-DE-014 to the released German disclosure pattern without searching 4 tools.

I would make one immutable Release Manifest the contract tying design assets, code artifacts, documentation, and migration obligations to the same version.

• It records each artifact's expected version, checksum, publish status, and timestamp across Figma, npm, Swift, Android, and Storybook, then blocks a release when parity checks fail.
• Its changelog separates added, changed, deprecated, removed, and fixed items, with visual diffs and affected component links so consumers can assess impact without opening Figma.
• Any artifact still mismatched after 24 hours has a named recovery owner and rollback path, while every breaking item includes its replacement, compatibility window, removal version, and migration steps.

I would publish one semantic token contract that defines visual intent, implementation values, locale behavior, and reduced-motion behavior together.

• Typography roles such as body-sm and heading-lg specify font family, weight, size, line height, and fallback stack, while spacing roles map to one 4 px scale instead of screen-specific values.
• A 6-locale fixture set covers every component with real strings, 30% text expansion, wrapping, truncation, and font-fallback checks at 320 px and 1440 px widths.
• Each motion token specifies duration, easing, property, and purpose, plus a prefers-reduced-motion mapping that removes spatial travel and preserves necessary state feedback through an instant change or a 100 ms opacity transition.

I would separate component coverage from end-to-end flow quality so a high average cannot hide a broken critical journey.

• Each of the 140 released components gets a row for required states, token conformance, keyboard behavior, screen-reader semantics, 6-locale rendering, responsive behavior, owner, version, and open exception.
• I report each criterion as passing components divided by 140, and any accessibility failure or missing destructive-action state is a blocker rather than a score that can be averaged away.
• The 10 critical flows run as versioned scenarios at 320 px and 1440 px, in all 6 locales and with reduced motion, tracking completion, visual-regression failures, accessibility failures, and system bypasses.

I would report the 3 dimensions separately against eligible product surfaces so one strong metric cannot hide a weak one.

• Supported coverage would be correctly implemented system-backed patterns divided by eligible patterns, excluding documented unsupported cases; I would target 85 percent and show Figma-to-code parity as a separate check.
• Cycle time would compare the median days from approved design to production for matched work, for example 12 days before adoption versus 9 after, rather than crediting the system for unrelated small tickets.
• Defects would count design-system-attributable visual, interaction, and accessibility issues per 100 releases, with a target below 2 and every P1 shown separately instead of averaged away.

I would use the 12 sessions as two structured learning rounds rather than one final-score study.

• Map every branch, dependency, permission boundary, save point, and irreversible choice in a task matrix, then select one common setup task and one role-specific high-risk task per cohort.
• Recruit four novices, four experts, and four administrators, running two from each cohort before revision and two after revision so early structural failures do not consume the full sample.
• Test an instrumented coded prototype with seeded accounts and realistic validation, recording completion, time per step, backtracks, help requests, recovery, and configuration accuracy in Lookback and Dovetail.

I would preregister the comparison, quality rules, and exclusions before launching the 300-person Maze study.

• Randomly assign about 150 qualified respondents to each version, stratified by role and device, and use the same three outcome-based tasks without wording that reveals the target control.
• Set primary task success plus secondary time, misclick, and confidence measures, estimating the detectable effect before launch and preserving assignment in the main analysis.
• Exclude duplicates, failed attention checks, impossible times, inactivity, and contradictory screeners only through thresholds fixed in advance, then report exclusions and sensitivity results.