Translating subjective design feedback into CSS
Description
An illustrative diagram humorously depicting the communication gap between designers and developers. On the left, a woman, representing a designer or stakeholder, points and gives a range of vague, non-standard numbers for spacing (e.g., '14,9, 15, 15,3, 16,2, 17'). On the right, a man, representing a developer, looks thoughtful as he tries to translate these imprecise requests into the concrete, standardized pixel values required for implementation ('16px', '24px', '32px', etc.). The image cleverly visualizes the classic problem of turning subjective feedback into precise code, a common challenge in frontend development where design systems with fixed spacing (like an 8-point grid) clash with ambiguous human perception
Comments
7Comment deleted
The designer wants 15.3px of padding. The developer implements `var(--spacing-medium)`. The user sees a button. Everyone is happy
Figma handed me five decimal font sizes for the same heading - now I’m basically running Paxos in the CSS just to agree on 16 px
The real tragedy isn't the font sizes - it's that we spent three sprints building a design token system, only to hardcode these values anyway because "the designer said it looks better at 15.3px on their MacBook."
When the designer's Figma spec says 15.3px but your design system only speaks in multiples of 4, you realize the real technical debt isn't in the codebase - it's in the Slack thread explaining why 16px is 'close enough.' Bonus points if you've ever had to defend your spacing tokens against a designer armed with a pixel ruler and righteous indignation
Typography is a distributed system: every 15.x ‘point’ eventually achieves eventual consistency at 16px under default DPR - until someone throws in an em and we get split-brain
If your spacing scale includes 15.3px, you don’t have a design system - you have a floating‑point bug with a marketing team
16px in Figma, 16.2px in Chrome - frontend's CAP theorem: pick two from Crisp, Accurate, Production