Product Designer interview questions

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.
• Style Dictionary would emit CSS custom properties, Swift asset values, and Jetpack Compose values, while CI checks unresolved references and snapshots all 12 platform-brand-theme combinations before release.

I would share a headless calendar and selection model, then inject domain policies instead of stretching one component with product-specific booleans.

• The DateRange Contract would use date-only LocalDate values plus an explicit product timezone and declare whether the end is inclusive; booking maps May 10 to 12 as 2 nights, while analytics maps it as 3 reporting days.
• A policy interface would provide isDateSelectable, validateRange, and normalizeRange; booking rejects a blocked night, while analytics rejects day 91, avoiding flags such as isBooking that couple the package to products.
• Presentation slots would share keyboard navigation, focus, and month rendering, but booking supplies nightly prices and analytics supplies 7-day and 30-day presets; that costs 2 thin wrappers but keeps accessibility behavior in one place.
• Storybook would hold 8 contract fixtures, including DST, a blocked middle night, and the 90-day boundary, with the same fixtures run against React unit tests before a minor release.

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.
• CI would fail on checksum drift or Chromatic visual changes without approval and target a 30-minute release SLA; the cost is maintaining one sync service, not 4 manual handoffs.

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.
• One maintainer would rotate as weekly triage owner with a 2-day acknowledgment SLA, and requests would enter fast fix, extension, experimental pattern, or reject lanes so 60-minute reviews are reserved for public API changes.
• A stable component would need approval from 2 of the 3 maintainers plus 1 adopting squad; an experimental component could ship after 1 maintainer review but must prove use in 2 squads within 2 releases.
• The contributing squad would fund implementation and documentation, while core maintainers fund final review; this saves scarce core capacity but costs contributors roughly 20 percent more delivery time than a local component.

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.
• Chromatic baselines and consumer tests would gate every wave; I would remove the shim only after 9 of 9 apps pass, then announce version 2 end-of-support with a fixed date rather than silently breaking stragglers.

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 reconsider a headless shared workflow only after 3 consumers share at least 80 percent of transitions for 2 quarters; accepting temporary orchestration duplication costs code, but avoids a false abstraction that slows all 3 products.

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.
• A local exception would become a shared variant only after at least 2 jurisdictions require the same behavior; the registry adds review overhead, but prevents one market's rule from permanently complicating every consumer.

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.
• The Adoption Scorecard would use red, amber, and green thresholds per dimension, not a weighted total; classification costs each squad about 2 hours monthly, but avoids a vanity score built from noisy telemetry.

I would turn intake into an explicit capacity allocation system, not a queue where every request quietly becomes a project.

• One form would require the decision needed, affected users, evidence, deadline driver, sponsor, and requested service; incomplete requests receive office hours rather than consuming one of 4 WIP slots.
• Twice-weekly triage would score user harm, strategic reuse, deadline rigidity, and effort, then route work to urgent, scheduled, consult, self-serve, or decline with a decision inside 5 business days.
• The Intake Capacity Board would reserve 20 percent of the 26 person-weeks for regulatory surprises and cap active work at 2 engagements per designer, because loading each person with 5 requests only lengthens every cycle.
• For 60 quarterly requests, I would plan roughly 15 full engagements, 25 consultations, and 20 deferred or declined items, then publish demand, wait time, and reasons so leaders can fund the gap instead of hiding it as overtime.

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

• The manifest would record version 4.6.0, Figma library key and publish ID, npm, Swift, and Android package versions, token checksum, Storybook URL, release status, and timestamp for provenance.
• Its changelog would separate added, changed, deprecated, removed, and fixed items, with Chromatic diffs and affected component links so 9 consuming apps can assess impact without opening Figma.
• Every breaking or deprecated item would include replacement API, codemod or manual steps, compatibility window, removal version, and migration owner; a major release could not publish without that migration contract.
• A release candidate would freeze Figma and code, pass visual and contract tests, then publish all artifacts inside the 24-hour window; the freeze slows last-minute edits, but a failed target can roll back to the previous manifest as one known set.

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.
• Figma variables and Style Dictionary share the same token names, while CI blocks missing mappings and the release artifact records version, owner, exceptions, and migration instructions.

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.
• A monthly scorecard links Storybook evidence and test runs, requires 10 of 10 flows to have no blocker, and assigns every failed criterion a named owner and target date.

I would anchor the tree on a precisely defined value event and keep diagnostic steps separate from activation itself.

• The activation rate is eligible first-time signups that finish setup and complete their first core task within 7 calendar days of account creation divided by all eligible first-time signups in the same signup cohort.
• The tree connects signup eligibility, setup start, setup completion, first-task attempt, first-task success, and 7-day activation, with cuts by acquisition channel, locale, device, and stated job.
• Before redesign, I freeze a 4-complete-week baseline for every node and run the same scripted core task with 100 representative first-time users, defining success as completion without moderator help within 5 minutes.
• The measurement brief stores event definitions, exclusions, the 7-day cohort-maturity rule, the usability script, segment quotas, and the baseline numerator and denominator so the post-launch comparison cannot redefine success.

I would define every checkout measure around a stable checkout_id and give delayed outcomes enough time to mature.

• Weekly starts are 100,000 unique checkout_ids that reach the first payment step in an ISO week, after excluding test, employee, and confirmed bot traffic; retries keep the original checkout_id.
• Conversion is checkout_ids with a first successful capture within 24 hours divided by all eligible checkout starts, so repeated captures never increase conversion.
• Duplicate-charge rate is completed checkout_ids with more than one successful capture for the same order within 24 hours divided by checkout_ids with at least one successful capture, while 30-day refund rate is refunded completed orders divided by completed orders with a full 30-day observation window.
• Completion time is the elapsed time from first payment-step view to first successful capture, reported as median and 90th percentile for converted checkouts, with the 24-hour abandonment rate reported beside it to expose survivor bias.

I would preserve one protocol and translate the percentages into observable participant outcomes.

• Success means completing the fixed critical task without moderator help and without a critical error within 5 minutes, making the baseline 70 of 120 participants at 58.3% and the target 90 of 120 at 75%.
• The baseline and follow-up use the same segment quotas, device mix, starting state, instructions, prototype fidelity, and moderator rules, with participant-level results stored in the benchmark sheet.
• I report median and 90th-percentile time for successful attempts, time-to-stop for all 120 attempts with failures capped at 5 minutes, and critical errors per attempt using a prewritten severity rubric.
• I accept the target only if at least 90 of 120 succeed and neither median time nor critical errors per 120 attempts worsen beyond the pre-registered tolerance.

I would calculate net capacity from observed case handling and label it as savings only when the organization can actually use or remove that capacity.

• A 2-minute reduction across 20,000 eligible cases equals 40,000 minutes, or 666.7 gross staff hours per month, before subtracting new review, training, and exception-handling time.
• Rework capacity uses 20,000 multiplied by the baseline rework rate minus the new rework rate, then multiplied by verified minutes per reworked case; a drop from 8% to 5% at 12 minutes adds 7,200 minutes, or 120 hours.
• The monthly capacity case is therefore 786.7 hours in that example, converted to cases using the new median handling time and to value using the loaded hourly labor cost.
• The benefits ledger separates cash savings from redeployed capacity, records case mix and quality guardrails, and requires 8 complete post-launch weeks before annualizing the result.

I would make reciprocal contribution the value metric and treat invitations as an upstream diagnostic.

• An eligible pair begins when one member invites another to a shared object, and each unordered member pair is counted once even if multiple invitations are sent.
• The 7-day reciprocal-contribution rate is accepted pairs where both distinct members make at least one qualifying contribution within 7 calendar days of acceptance divided by all accepted eligible pairs.
• A qualifying contribution is an edit, substantive comment, task assignment, or resolution on the shared object; views, reactions, automated changes, and duplicate comments do not qualify.
• I segment by team size and new versus existing relationships, then track contribution on days 8 to 30, invitation dismissals, blocks, and abuse reports to detect shallow or coerced collaboration.

I would keep click-through as a diagnostic and judge recommendation quality by the durable outcome after acceptance.

• Click-through rate is clicked recommendation impressions divided by eligible recommendation impressions, deduplicated to one impression per recommendation, user, and session.
• The 14-day accepted-outcome rate is impressions where the user accepts the recommendation, completes the intended downstream action, and leaves it in effect for 14 days divided by all eligible impressions.
• Reversal rate is accepted recommendations undone, cancelled, or manually replaced within 14 days divided by all accepted recommendations with a mature 14-day window.
• Regret rate is mature accepted recommendations followed by an explicit not-useful response or a regret survey score of 1 or 2 out of 5 within 14 days divided by accepted recommendations that received the corresponding feedback opportunity.

I would treat activation as a leading metric and 30-day retention as a durable-value countermetric, then test whether the onboarding change altered who activates or what activation means.

• Activation remains activated eligible signups divided by all eligible signups within 7 days, while 30-day retention is activated users who perform the core task on days 30 through 36 divided by activated users whose full retention window has matured.
• I compare pre-change, post-change, and any randomized holdout cohorts within the same acquisition channel, locale, device, stated intent, signup week, and eligibility rules rather than relying on aggregate trends.
• I verify event definitions and instrumentation, then decompose setup completion, first core task, repeat core task, time to second use, and retention to locate where the relationship breaks.
• I use the holdout or a staged cohort test to estimate causality and revise the activation milestone if it predicts shallow completion, while keeping rollout decisions tied to the pre-agreed retention threshold rather than an incident response.

I would register one conversion hypothesis and three harm thresholds before exposure so the team cannot excuse a harmful win after seeing results.

• The primary metric is completed orders within 24 hours divided by eligible unique checkout starts, with a goal of at least 3% relative lift over 14 complete days and analysis by assigned variant.
• Checkout-complaint rate is unique substantiated checkout complaints within 7 days divided by completed orders, with a stop threshold of a 0.20 percentage-point absolute increase whose 95% confidence interval excludes zero.
• Support-contact rate is users with at least one checkout-tagged contact within 7 days divided by completed orders, with a stop threshold of 5% relative increase, while 30-day refund rate is refunded orders divided by completed orders with a mature 30-day window and a 0.30 percentage-point absolute limit.
• The pre-registration records exclusions, sample-size rule, event queries, segment cuts, thresholds, and decision logic, and shipping requires the conversion goal plus all 3 guardrails to pass after their stated windows mature.