Distinguish a system violation from a local inconsistency or personal preference.
Design review · Workhuman AI practice
Measure before correcting
I adapted the critique workflow to Recognition: measure the design, identify the source of the discrepancy and propose the smallest appropriate correction.
design-critique
The problem
Why this belongs
in the workflow.
What looks like an inconsistent gap may come from component padding or internal alignment. Changing the wrong layer can damage the intended behaviour.
What the skill makes explicit.
Consult the product’s component and pattern context before recommending changes.
Keep foundation ownership explicit and avoid changing another team’s system.
Evidence and learning
From instructions
to practice.
A documented incident separates visible spacing into gap, padding and internal alignment. That diagnosis protects the touch target from a cosmetic “fix”.
Contribution and evidence scope
This is an adaptation of an existing critique skill. The incident is recorded in its instructions; it was not independently replayed for this portfolio.
Source: the supplied design-critique skill and associated records. Internal component identifiers and company endpoints are omitted.
Process flow
How this skill handles a task.
What looks like an inconsistent gap may come from component padding or internal alignment. Changing the wrong layer can damage the intended behaviour.
- 01
Measure
Read actual styles, layout values and rendered output.
- 02
Classify the issue
Separate system violations, inconsistency and preference.
- 03
Inspect states
Check the component and the relevant product context.
- 04
Recommend a change
Propose the smallest correction within the right ownership.
DECISION CHECKPOINT
Is the issue verifiable?
Proceed
Cite the measured issue and recommend a scoped correction.
Alternative / follow-up
Label subjective feedback as preference.
Editorial map of the documented instructions, not a recorded execution.
Inside the skill
Instructions you can inspect.
Useful critique is verifiable. Every point cites the node and the rule it breaks, or says openly that it is a preference. A paragraph of impressions changes no design.
What I need
• The design — Figma URL, screenshot, or a description. With a Figma URL, pull the design;
with a file reference, read it.
• Context — what is this, who is it for.
• Stage — exploration, refinement, or final polish. Early exploration gets feedback about
the concept and the flow; final polish gets feedback about tokens, states and a11y. Getting this backwards is the fastest way to be useless.
• Focus (optional) — "only the navigation", "only mobile".
If the stage is not stated, ask — one line, not a questionnaire.