The user's explicit instructions take precedence over this skill.
Review the interface against the expectations of its intended audience, not against a universal preference for simplicity, spaciousness, or beginner-friendliness.
Core judgment
Complexity is not the same as confusion.
A dense interface can be appropriate when expert users repeatedly perform complex tasks and need many signals at once. A visually simple interface can still be confusing if it hides state, uses unclear terminology, loses context, or makes recovery difficult.
Evaluate whether the interface helps its real users perform their real tasks with appropriate speed, confidence, and recoverability.
Establish the audience model
Use repository context, product copy, user-provided context, and the interface itself to infer:
- user expertise
- first-use versus repeated-use frequency
- task complexity and stakes
- exploratory versus operational work
- expected information density
- keyboard versus pointer dependence
- domain vocabulary users already know
- common versus rare actions
- acceptable cognitive load
- consequences of mistakes
Do not assume that every term must be explained, every option hidden, or every workflow reduced to a wizard.
If the audience is materially ambiguous and the user has not specified it, state the assumption in the review rather than silently reviewing for a generic consumer audience.
Review behavior
Judge the interface at the task level and state level, not only component by component.
Pay particular attention to:
- visibility of system status
- clarity of the current mode, selection, scope, and location
- mapping between controls and outcomes
- information architecture and grouping
- recognition versus unnecessary recall
- consistency with domain and platform conventions
- error prevention, recovery, and reversibility
- efficiency for repeated expert use
- discoverability for first or infrequent use
- keyboard flow and focus when relevant
- terminology appropriate to the audience
- progressive disclosure that hides only what can safely be hidden
- destructive actions and irreversible consequences
- loading, empty, partial, error, disconnected, and success states
Do not optimize for a generic consumer app
Do not recommend lower density, larger cards, more whitespace, friendlier terminology, tutorials, or hidden advanced controls unless those changes improve the target users' actual task performance.
Likewise, do not defend complexity merely because users are experts. Experts still need clear system state, predictable behavior, recoverable errors, and efficient navigation.
Recommendations
Prefer findings phrased as a user-task failure or friction point:
- what the user is trying to know or do
- what the interface currently makes difficult or ambiguous
- why that matters for this audience
- the smallest change that addresses it
Separate:
- real usability issues
- audience-appropriate complexity that should remain
- visual preference or taste
- missing evidence or assumptions
Do not redesign the whole interface when a smaller structural or behavioral fix is sufficient.
Supporting references
Read references/audience-model.md when calibrating standards for the product's users.
Read references/review-lenses.md when performing a detailed usability review.