Q367: Design Critique Loop Simulation Product UI Accessibility and Tradeoffs

What Interviewers Want To Evaluate

Design critique simulations test whether you can review UI without turning the conversation into taste.

Interviewers want to hear how you evaluate product goals, hierarchy, accessibility, responsive behavior, interaction states, design system consistency, performance, and implementation cost.

A senior frontend engineer should critique with evidence and empathy.

Short Interview Answer

In a design critique, I start with the user goal and success metric, then evaluate hierarchy, flow, interaction states, accessibility, responsive behavior, consistency with the design system, implementation complexity, and measurement. I avoid taste-based feedback and frame trade-offs clearly so product, design, and engineering can decide together.

Simulation Prompt

Review a dashboard redesign.

The new design includes:

large hero summary
dense metric cards
filter sidebar
data table
export action
chart area
mobile layout

Explain your critique process.

Start With Goal

Ask:

What user decision does this dashboard support?
Which metric matters most?
Who uses this daily?
What action should be easiest?
What changed from the current design?

Critique without goal becomes personal preference.

Hierarchy

Review:

primary information
secondary information
action priority
scan order
visual density
empty states
error states

For dashboards, density can be good.

The question is whether the density helps decision-making.

Interaction States

Check:

loading
empty
error
filtered empty
permission denied
export pending
chart hover
table row selected

Designs often show the happy path.

Frontend engineers should ask for the real states.

Accessibility

Review:

heading order
keyboard access
focus visibility
color contrast
table semantics
chart alternatives
form labels
touch targets
reduced motion

Accessibility feedback should be specific.

Do not say only that it needs accessibility.

Say which behavior needs support.

Responsive Behavior

Ask:

What happens to the sidebar on mobile?
Does the table become cards, scroll, or summarize?
Which metrics stay visible?
How does export work on touch devices?
Are filters easy to reset?

Responsive design is not shrinking desktop.

It is choosing priorities per viewport.

Implementation Trade-offs

Discuss:

custom table vs existing grid
chart library weight
sticky filters vs simple top controls
virtualization need
server-side filtering
export responsibility

Design critique should include build risk without using engineering cost as a blunt no.

Feedback Language

Use:

The goal seems to be...
The hierarchy supports that because...
One risk is...
I would test...
The trade-off is...

This keeps the critique collaborative.

Common Mistakes

• Giving taste-based feedback.
• Ignoring product goal.
• Forgetting loading and error states.
• Treating accessibility as a final audit.
• Not discussing mobile.
• Saying something is hard without alternatives.
• Overriding design instead of partnering.

Final Mental Model

Design critique is:

goal
hierarchy
states
accessibility
responsive behavior
system consistency
implementation trade-offs
measurement

Senior critique helps the team make a better decision, not just a prettier screen.