zlacker

>>emilsj+(OP)
The problem with these kind of pixel-perfect, inspectable design tools, is that there's no distinction between important details and unimportant details.

For example, if our app uses a letter-spacing of 1.2 for all the body text, and your Figma design uses a letter-spacing of 1.25, is that important? Or is that a mistake?

In something like Figma, being consistent is difficult for designers. But in code, being consistent is the default — exceptions are hard for developers!

There's a fundamental mismatch that just ends up being painful all around.

"The map is not the territory." Trying to get a design doc to 100% accuracy is often a waste of time. Design tools need a way to specify which details are important, and which are not.

>>natero+rD1
When writing CSS for a Figma design, I first try to match the Figma as exactly as is reasonable, then I do a visual diff to make sure I haven’t missed any important details, then I clean up the CSS and relax some of the constraints until the (S)CSS is maintainable e.g. if I have padding of 19 and 21, lifting that out into a $padding: 20px constant.

>>zarzav+0S1
Mockups are mockups, they’re suggestions. More often than not, sizes and spacing don’t match across views and it’s a waste of time to be “pixel perfect.”

>>bunga-+BW1
As I said, I don’t try to make the end result pixel perfect. I try to cut a balance between being faithful to the design and having maintainable code.

Spacing and sizes do matter though. There’s a reason why we have thousands of different fonts, even though 5 would be sufficient. When lengths are proportionate it creates positive feelings in the user. People are unconsciously very perceptive to small changes in proportions - it’s sexual attraction.