UI Designer interview questions

I would share stable semantic controls across products and keep business workflows inside each product.

• I would classify all 60 candidates by purpose, states, interaction, and accessibility behavior because visual similarity alone does not make two components equivalent.
• A component enters the shared layer only when at least 2 of the 3 products need the same contract; workflow assemblies, product copy, and data rules stay local.
• The shared layer owns tokens, primitives, and controls such as Button or Select, while each product owns how those controls compose into a task.
• I would deliver a topology map assigning every one of the 180 components a keep, merge, wrap, or retire decision, plus its canonical target and migration dependencies.

I would replace the 48-combination surface with 9 visual families and an explicit runtime state.

• appearance accepts primary, secondary, or tertiary, and size accepts small, medium, or large, giving 3 by 3 supported visual families instead of competing booleans.
• state is idle, loading, or disabled, so loading and disabled cannot be switched on together and the click behavior is defined for each state.
• Leading and trailing content use named slots, while an icon-only action becomes IconButton because its accessible name and geometry have a different contract.
• A Figma component set and Storybook matrix show the 9 visual families across 3 runtime states, while typed props reject every unsupported pairing.

I would replace 30 named variants with one behavioral core, explicit capabilities, and product-owned compositions.

• The core owns row and column semantics, sorting, selection, keyboard behavior, focus, and pagination contracts.
• Cell renderers, toolbars, filters, empty states, and product-specific actions stay in slots or surrounding composition rather than becoming new table variants.
• I would map each of the 30 variants to the capabilities it actually uses, then provide compatibility adapters so one of the 8 products can migrate at a time.
• A variant is retired only after its Storybook states, interaction tests, and consumer screenshots match the approved replacement, with removal tracked separately for all 8 products.

I would share visual status primitives but keep InlineMessage, Banner, and Toast as separate public components because their persistence and interaction contracts differ.

• InlineMessage stays attached to a field or content region, reserves local space, and exposes a programmatic description when it explains an error.
• Banner participates in page layout, stays until the condition changes or the user dismisses it, and may contain recovery actions tied to the page-level issue.
• Toast is time-limited and reserved for noncritical confirmation; it cannot contain a required action, and its pause, dismiss, and announcement behavior are explicit.
• I would map all 24 patterns to one of the 3 contracts, list the shared icon, color, type, and spacing primitives, and reject any variant that mixes their semantics.

I would share an internal positioning primitive but keep Tooltip, Popover, and Menu as separate semantic components.

• Tooltip contains supplementary noninteractive text, opens from hover or focus after the specified delay, closes on Escape, and never receives focus itself.
• Popover contains interactive content, defines initial and return focus plus outside-click and Escape behavior, while Menu owns an action-list model with arrow-key navigation and typeahead.
• I would map all 24 patterns by trigger, content, focus model, keyboard behavior, dismissal, and ARIA role, then replace mixed cases instead of adding mode props to one floating component.
• Storybook acceptance covers mouse, keyboard, touch, open and closed states, focus return, and nested-layer restrictions for each of the 3 public contracts.

I would classify all 14 requests by whether they change a finite semantic axis, replace content, assemble existing parts, or change the component's identity.

• I use a prop only for a closed, enumerable choice that keeps anatomy and behavior stable, such as size or emphasis.
• I use a named slot when the region and responsibility stay fixed but its content varies, such as a leading visual or footer action.
• I use composition when the request combines existing controls into a product workflow, so the shared component does not acquire layout or business rules.
• I create a separate component when semantics, focus model, state ownership, or required anatomy diverge, and the classification worksheet records one of these 4 outcomes for each of the 14 requests.

I would share one modal foundation for overlay mechanics and expose Dialog, AlertDialog, and Sheet as separate public contracts.

• The foundation owns portal placement, scroll locking, focus containment and return, backdrop behavior, labelling, and Escape handling without owning product content.
• Dialog supports general interactive content, AlertDialog requires an explicit decision and a safe initial-focus rule, and Sheet adds edge placement, drag affordance, and responsive dismissal behavior.
• I would map all 22 variants to those 3 contracts by purpose, focus model, dismissal, and anatomy; a visual difference becomes a theme or size property only when behavior stays unchanged.
• The release specimen covers open, closing, long content, nested trigger, error, and mobile states, with the same foundation tests reused by all 3 components.

I would keep the component in candidate status until the 2 pilots prove one public contract, then promote it through a written release scorecard.

• Both pilots must use the same semantic core without importing internals or adding product-specific props; any escape hatch reopens the API decision.
• The beta gate requires documented states, tokens, keyboard behavior, screen-reader output, responsive behavior, and Storybook interaction and visual tests.
• Stable status requires both pilots to ship through 1 release cycle with no breaking contract change and with migration notes for any renamed API.
• The remaining 4 teams receive examples and can validate fit, but their adoption is not required to stabilize a contract already proven by the 2 real consumers.

I would specify 3 navigation modes with content-driven transitions and test them across the full 320 to 1440 CSS px range.

• Compact mode keeps brand, current destination, primary action, and menu trigger; intermediate mode exposes priority links plus overflow; expanded mode shows all primary links.
• Container queries switch modes when the measured labels and actions stop fitting, rather than assuming that one device width works for every locale.
• The matrix verifies 320, 375, 768, 1024, and 1440 CSS px plus 200% zoom, long labels, active state, keyboard order, and open-menu state.
• Every mode preserves destination order and accessible names, uses at least 44 by 44 CSS px targets, and prevents duplicate focus stops when links move into overflow.

I would enforce one-way dependencies from patterns to controls to primitives and remove all 9 cycles before the next component release.

• Foundations contain tokens only, primitives contain low-level structure, controls own a single interaction contract, and patterns compose controls without being imported back into lower layers.
• I would break each cycle by extracting the smallest shared primitive or moving product composition upward, not by hiding the import behind another alias.
• A generated dependency graph lists all 70 components, layer, direct imports, consumers, and cycle path, while lint rules reject imports that point upward.
• The release gate requires zero cycles, no product package imported by the shared library, and a migration target for every public export moved between layers.

I would deliver one three-layer taxonomy with six fully resolved theme outputs, not six separate token trees.

• Primitives hold raw values such as color.brand.alpha.600, color.neutral.0, and space.200; they never appear in component code.
• Semantic tokens such as color.text.primary, color.surface.canvas, and color.action.primary map primitives by brand and mode and form the public product contract.
• Component tokens such as button.primary.background.hover exist only when a stable local need cannot use a semantic role, and they alias semantic tokens rather than raw colors.
• A generated matrix lists every token across Alpha and Beta in light, dark, and high contrast; CI fails on missing mappings, cycles, or unresolved references.

I would publish a theme manifest containing exactly 12 identifiers and compile each one into a complete semantic bundle.

• The manifest takes brand from a four-value enum and mode from light | dark | high-contrast; runtime code rejects any identifier outside the 4 by 3 Cartesian set instead of silently falling back.
• Shared mode foundations provide neutral surfaces, text, borders, and states, while each brand supplies only its approved semantic overrides; the build resolves inheritance before publishing.
• CI checks all semantic roles, text and non-text contrast, focus states, and visual snapshots for representative controls in every one of the 12 bundles.

I would keep #6B4EFF as the canonical brand primitive but stop assigning it directly to normal text on that surface.

• I would create a semantic color.text.brand value from the nearest approved tint or shade that measures at least 4.5:1 against each actual background, then record the tested pair in the token metadata.
• The original hue can remain in larger fills, illustrations, and decorative accents; for meaningful icons or control boundaries I still require at least 3:1 against adjacent colors.
• Large text may use a 3:1 pairing only when it meets the WCAG large-text definition, not merely because the design labels it a heading.
• Automated contrast tests run on every brand and mode mapping so a later palette change cannot restore the failing text pair.

I would produce an alias dependency graph and migration manifest, with a release gate of zero cycles and no path longer than two alias hops.

• The graph records each alias, resolved value in every supported theme, consumer count, and path, which exposes unused names, duplicate intent, and chains created for one-off overrides.
• I would remove zero-consumer aliases and merge names only when their purpose and theme behavior match; equal current values such as text.muted and border.subtle remain separate when their meanings differ.
• The migration manifest maps every retired name to a replacement or an explicit deletion, and a codemod updates code consumers while a Figma report identifies affected variables.

I would admit a component token only for independently themeable behavior that the shared semantic layer cannot express, under a budget of 280 across the library and a review trigger above eight for one component.

• The request must show the property changing independently in at least two supported themes and across at least three production uses of that component; a single mockup or one brand override is not enough.
• Each token uses component.<name>.<property>.<state>, aliases an existing semantic role by default, and documents states, fallback, and why a new global semantic role would be misleading.
• CI reports the 280-token budget and per-component distribution; crossing either threshold requires a recorded exception with the theme matrix, rejected alternatives, and removal criteria.
• The cap is a complexity alarm rather than permission to fill a quota, so components with no proven independent variation receive no local tokens.

I would make versioned DTCG JSON in Git the source of truth and give every published output the same source hash.

• Canonical DTCG IDs stay in the repository, while a mapping table links each one to the Figma Variable ID that Figma creates.
• On merge, schema and alias validation run first, then Style Dictionary builds CSS custom properties and platform artifacts and publishes an immutable package.
• Where the plan and permissions allow Variables API writes, an authenticated sync service updates Figma and records the source hash; the workflow never assumes that CI can launch a desktop plugin remotely.
• A drift check compares DTCG IDs, Figma variable IDs, resolved values, and package manifests and alerts if the package and Figma are not synchronized within 30 minutes.

I would publish one versioned token release with platform-specific artifacts and a compatibility manifest for all 40 consumers.

• A major version removes or renames a token or changes its type or meaning, a minor version adds backward-compatible tokens or themes, and a patch corrects a value without changing documented intent.
• The build emits an npm package for web, a Swift package for iOS, a Maven artifact for Android, and resolved JSON plus CSS-safe values for email, all stamped with the same version and source hash.
• Every release includes resolved diffs by theme, deprecations with replacements, and platform snapshots; a breaking release also ships a rename map and migration examples.
• A machine-readable registry records the version range declared by each of the 40 consumers and blocks removal while any supported range still depends on the deprecated contract.

I would resolve brand from the tenant and mode from a fixed user-over-system precedence before the first UI paint.

• The tenant selects one of 2 brands; the signed-in user choice of light, dark, or high contrast overrides the operating-system color preference, and the product default applies only when neither is available.
• The resolved theme is expressed as data-brand and data-mode on the root, with all components consuming semantic tokens rather than brand or mode conditionals.
• Server rendering or an inline bootstrap reads the persisted choice before CSS paints, so reload, sign-in, and tenant switching do not flash the wrong one of the 6 themes.
• The acceptance matrix covers all 6 themes plus user override, cleared preference, system change, reload, sign-in, and tenant switch, with the resolved source visible for debugging.

I would define elevation by spatial purpose and order, then map that meaning to native rendering on each platform.

• The source exposes elevation.base, elevation.raised, elevation.overlay, and elevation.modal, with usage and stacking constraints instead of shared shadow values.
• Web maps those roles to progressively stronger shadow, border, and z-index tokens; Android maps them to surface, surfaceContainerLow, surfaceContainerHigh, and surfaceContainerHighest tonal roles.
• Contract tests verify the same ordering, occlusion, focus treatment, and content contrast on both platforms, while snapshots are allowed to look visually different.

I would generate the token reference from governed metadata in the canonical DTCG files, never from a separately maintained documentation table.

• Every one of the 300 tokens must provide stable ID, name, type, intent, allowed and prohibited contexts, status, and replacement when deprecated; semantic and component tokens also declare accessibility notes and fallback behavior.
• The generated page shows the alias path, resolved value in all 12 supported themes, Figma variable link, and copyable web, iOS, Android, and email output names.
• Schema validation fails the build for missing required metadata, broken references, duplicate IDs, or a deprecated token without a replacement or explicit removal note.
• The generator also emits a searchable tokens-index.json and version diff, so documentation, release notes, and platform packages can be checked against the same source hash.