UI Designer interview questions

I build the hierarchy around the decisions users need to make on the reporting screen.

• I rank metrics, filters, alerts, and the table by their role in the task rather than by stakeholder ownership.
• I use position, scale, contrast, and spacing to make the primary decision path clear.
• I test the result with realistic values, long labels, and an active alert to confirm the hierarchy holds.

Lower visual density becomes harmful when it slows down comparison and obscures related information.

• Extra spacing can separate values that users need to scan as one group.
• A more spacious layout can also force excessive scrolling in data-heavy professional tasks.
• I preserve compact, scannable groups and offer density options only when workflows genuinely differ.

I distinguish the panel that drives the current task without making the second panel disappear.

• I give the task-driving panel the stronger position, contrast, and action emphasis.
• I keep the other panel discoverable but visually quieter so it does not compete for attention.
• If its state later requires intervention, I increase its urgency through an appropriate status treatment.

A long settings page needs clear grouping before it needs more containers.

• I use headings and spacing to separate meaningful sections and show their relative importance.
• I rely on alignment and dividers to reinforce relationships without wrapping every section in a card.
• When the section count makes retrieval difficult, I add search or sticky navigation.

I would diagnose the dashboard with representative production content rather than polished sample data.

• I inspect the full range of values, label wrapping, and missing-data states.
• I check alert frequency and whether multiple status colors compete for attention.
• I redesign with realistic extremes and specify truncation, wrapping, and overflow behavior explicitly.

I use progressive disclosure when secondary controls interrupt the common path without helping the immediate decision.

• I keep the main task and its most frequent controls visible.
• I reveal secondary options in context so users do not lose their place or current values.
• Critical status, required inputs, and the consequences of a decision always remain visible at the decision point.

I give each table row a stable structure so statuses can be scanned and actions remain predictable.

• Comparable statuses stay in consistent columns with clear visual treatment.
• The primary row action appears in the same location across all rows.
• Rare actions move into a clearly labeled overflow menu that remains accessible by keyboard.

I simplify the component by defining a small set of purposeful variants instead of supporting every property combination.

• I identify the combinations that correspond to real semantic roles in the interface.
• I remove unsupported pairings of size, tone, emphasis, and icon treatment.
• Named variants express intent, while flexible content composition covers genuine exceptions without arbitrary options.

Visually similar controls should remain separate when they promise different behavior to users.

• I compare their semantics and the interaction each control is expected to provide.
• I also check whether focus, keyboard use, labels, or other accessibility behavior differs.
• They may share visual foundations, but their component contracts should not hide meaningful differences.

I would replace many independent button treatments with a small set of mutually exclusive variants based on purpose.

• Variants receive semantic names such as primary or destructive rather than names based only on appearance.
• I define the allowed sizes and icon positions for each relevant variant.
• I document interactive states and prohibited combinations so the button remains consistent across products.

I specify this component as stable anatomy with explicit rules for every optional element and state.

• I define the order, alignment, spacing, and space reservation for the label, helper text, error, and counter.
• I show how each element wraps and which message takes priority when all content appears together.
• I document accessible naming and the association between the field and its error message.

The choice depends on whether the difference creates a recurring card role or only changes one layout.

• I first compare the requested behavior and meaning with the existing card contract.
• A repeated semantic role with consistent behavior can justify a named variant.
• An isolated content arrangement should use existing slots or composition rather than expanding the shared component.

A component specification should describe its complete behavior, not just the polished default view.

• I include anatomy, variants, states, content limits, and valid combinations.
• I define responsive rules and interaction behavior for relevant inputs and viewport conditions.
• I state accessibility expectations and illustrate boundary cases alongside standard examples.

I would deprecate the variant through a visible, staged transition rather than removing it at once.

• I map where the variant appears and assess the product risk of each use.
• I provide a clear replacement and explain any changes in appearance or behavior before migration starts.
• I phase adoption by risk and use regular audits to track the remaining instances.

I would separate a legitimate high-density need from a layout problem disguised by the compact variant.

• I review the task, content, and container constraints where the compact treatment appears.
• I keep the variant only when compactness improves a clearly defined dense workflow.
• Where it merely makes a poorly planned layout fit, I correct the layout and return to the standard variant.

A semantic token preserves why a color is used instead of tying the interface to one palette value.

• The token names the color's role, such as text, surface, focus, or status.
• That role can map to different values across themes and interaction states without changing its meaning.
• Palette values remain the visual ingredients underneath rather than product-facing decisions.

I choose spacing token scope by the recurrence and meaning of the relationship it represents.

• I begin with a shared spacing scale that covers general layout needs.
• I add a semantic spacing token only when the same relationship must stay stable across components.
• I avoid names tied to one screen or an arbitrary pixel value because they do not communicate reusable intent.

Passing contrast checks does not guarantee enough visual depth or hierarchy in a dark theme.

• I compare the elevation and relative luminance of adjacent surfaces.
• I inspect border visibility and whether text levels remain clearly distinguishable.
• I adjust the connected semantic roles as a system rather than brightening isolated elements.

Before changing tokens, I define the meanings the new accent color is allowed to carry.

• I separate brand expression from action emphasis, focus, selection, and status.
• I resolve collisions so one accent does not make different interface signals look equivalent.
• I then test contrast and consistency in every theme and interaction state.

I structure the token system in layers so shared components keep stable meaning across different brands.

• Foundational scales for color, spacing, and type remain separate from semantic roles.
• Each brand theme maps its own visual values onto the same semantic roles.
• I introduce component-level tokens only for controlled local decisions that broader roles cannot express safely.