Blog Post
Translating 'It Looks Wrong': A Developer's Guide to Vague Design Feedback
Vague design feedback like "it looks wrong" wastes hours because designers perceive visual gestalt while developers work in discrete CSS properties. This guide provides a 4-step framework: categorize the feedback, capture visual evidence, reference the Figma source of truth, and file structured issues.
"This looks off." "Something feels wrong with the spacing." "Can you just make it match the design?" If you build UI, you have received feedback like this. The problem is not lazy designers or oblivious developers — it is a vocabulary gap. Designers perceive visual gestalt. Developers work in discrete CSS properties. This guide provides a 4-step framework for bridging that gap.
"Designers and developers literally see interfaces differently. Designers process visual hierarchy holistically, while developers parse component trees. Neither perspective is wrong — but without a shared vocabulary, every review cycle costs the team 30-45 minutes of translation overhead per issue."
Step 1: Categorize the Feedback
Design issues fall into eight categories: color and visual properties, spacing and layout, typography, layout structure, missing elements, extra elements, accessibility, and responsive design. Knowing which category you are dealing with determines where to look and what CSS properties to measure.
| Category | What to look for | "Sounds like..." |
|---|---|---|
| Color & Visual | Wrong hex/RGB values, incorrect opacity | "The colors feel off" |
| Spacing & Layout | Incorrect padding, margin, or gap values | "It looks cramped" |
| Typography | Wrong font size, weight, line-height | "The text looks different" |
| Layout Structure | Elements in wrong position or alignment | "This doesn't look like the design" |
| Missing Elements | Components in spec but not in code | "Where's the...?" |
| Extra Elements | Components in code but not in spec | "What's this thing?" |
| Accessibility | Insufficient contrast, missing focus states | "I can't see this" |
| Responsive | Layout breaks at specific viewports | "Something's weird on mobile" |
Step 2: Capture Visual Evidence
Good visual evidence includes: the implementation screenshot with viewport metadata, the Figma design reference, a side-by-side or overlay comparison showing the difference, and environment metadata (browser, OS, viewport dimensions, device pixel ratio). A screenshot without context creates more ambiguity than it resolves.
Step 3: Reference the Source of Truth
Every piece of design feedback should link to the specific Figma frame, component, or token it references. Spacing values, color tokens, and typography specs are measurable, not subjective. When the spec does not account for a given state, that is a design gap — not a developer error.
Step 4: File Structured Issues
Type every issue correctly: Design Bug (implementation doesn't match spec), Design Gap (spec is missing or ambiguous), or Design Debt (shipped knowingly off-spec). Include severity, category, visual evidence, Figma reference, and a pin pointing to the exact element.
The Checklist
- What category does this feedback fall into?
- Do I have a screenshot with viewport metadata?
- Do I have the Figma frame this should match?
- Can I see the difference between implementation and spec?
- Is this a design bug, design gap, or design debt?
- Have I set severity and pinned the specific element?