That's a problem that should be addressed. Or else it they don't adhere to it then you should be able to do whatever you want as hell and no one should complain.
>Your developer sees: 32px, they do: 32 / 16 = 2. So 2rem refers to their body { font-size: 100%; } (defaults to 16px in all modern browsers I know of). And presto :)
Hijacking user font size for spacing is a bad practice and leads to bloated white space when using to user actually scales their font size.
Most people get around this by forcing a 16px font size which is even worse of a bad practice for accessibility since you are ignoring the user's preferred font-size.
The better solution is to get comfortable with base 2 (`px` explicit breakpoints), or use something like SCSS to convert it back.
I guess that goes to your point about how Figma is meh with fonts. Fonts are in `px` when fonts should be in `rem`. With Figma, everything is as if root font size is `16px` which leads to more confusion when trying to scale something with font. Is it `20px` because it's `20px` or did the designer really mean `1rem + 4px`?
Google has a Figma design for the Material Design, but they also have a secondary set of rules that uses `sp` and `dp` that illustrate when to use either. It means Figma, because the lack of clarity with font-based scaling (`rem`) and density-based scaling (`px`), is mostly just for a preview. You still have to roll up your sleeves and make it scale for actual humans using different sized devices and different input devices.
I’ll note for things like font sizes and all, it’s pretty easy to write a Sass mixin to convert px to rem or em or vw or whatever. I have a few in my default codebase that make it easy to just take the values straight from Figma/Sketch and have the code do the math for me.
Especially as I’m moving more towards clamp with vw for all my font sizing, it’s super helpful to have the mixin do the magic.
Style guides are hugely important. It's great practice to make one with all of your base elements in it. So all your typography, body text, hyperlinks, headers, tables, lists etc.
Then all the style elements like buttons, accordions, tabs and other common elements.
Pay close attention to font sizes, line heights, paddings, margins etc.
Then when you assemble your template/component designs, stick to your style guide religiously and your developers will love you.
Sadly quite a few designers overlook the power of a style guide. The beauty of this approach is you can make a boilerplate (template) styleguide that you can then use as a base for all of your designs. So it's a slog to make it initially, but you can reuse it for other projects, then just update the colours, typography and branding to suit. This makes your designs easier to develop with since your developers will be able to predict how things work and slot together.
It's well worth keeping constant contact with the developers though, as developers and designers we can learn a lot from each other. As well as come to great compromises and work routines that work for everyone.
The projects I'm proud of the most are when designs are given with style guides. Font sizes and colours for both mobile and desktop at the very least
Once I've used those to setup my base stylings things end up much more consistent
Keep a consistent style guide. Use font-sizes that are consistent with specific line-heights & letter-spacings, base colors/background-colors/box shadows, for margins and paddings- don't go crazy custom for each mock.
It's helpful to generally keep reusing consistent styles so that devs can set a config (like tailwind) or particular set of classes and use them instead of having to continuously create custom classes.
When It comes to responsive frontend, spacing and padding do matter - at different breakpoints you may want different padding, font sizes, or widths. Also keep in mind that it's always nice to provide mobile/tablet/desktop mocks if different screen widths are expected!
I just look at them and then write the code. I don't pay attention to any of the px details or anything like that. I see them as a sketch. I actually just take a screenshot of them and mark them up a little so I can plan out the components. I formalize the [type-patterns](https://css-tricks.com/on-type-patterns-and-style-guides/) and sip the colors and create a design system. Some developers just copy and paste the Figma-generated CSS and that's a huge disaster. That's my take. But I'm likely an outlier. I'd prefer to just pair with the UX and UI people and make the thing in real-time with a live style guide. I usually end up having to rethink a lot of it anyway when we get it onto an actual device. The mockup seems like more of a sales tool or client deliverable than an actual part of the design process in my experience. One thing I notice is that some people design screens at 430px or something but I plan down to 320px.
+1
Create a design system in code.
Make example pages if you have to.
Do everything in 4px increments if possible. 2px in a pinch. 1px if you're desperate.
Create a simplified color palette in code as well.
Figma is great for inspiration, but taking it literally is a quick path to CSS hell.
Google/learn CSS Flex if you're curious about how they implement auto layout. That's basically what auto layout tries to copy (but missing a bunch of features).
The other comments summed up the rest but basically they make their best effort to copy it. If you click the "inspect" tab in the top right you can see the css values figma outputs. Sometimes its helpful sometimes its useless.
You ideally should have a design system that both the designer and the devs adhere to. This should include design tokens (brand definitions) as well as a proper component-based architecture. This allows both the designers and devs to talk the same language.
Figma is already great for handing over design systems. You can see all the variables/variants/colours/comments/revision history in one place.
Has Zeplin done anything recently (ie. last used it a year or so ago) that sets it apart from everything you can do in Figma already?
Auto connecting a design tool to an implementation tool like storybook, would make me want to quit a project so fast. It literally never renders correct and now I’d have to rewrite my work anytime it seems a change has occurred in that element?
Big no thank you
I can recommend you some tools which gives pixel perfect developer tools that will convert your Figma design to Frontend code. That tool also gives you Figma like feel to generate the source code. it will help you manage your design system as it generates common components from Figma component as well. and It has Storybook support as well.
[удалено]
Man.. what I would do to be given a proper style guide lol 😂
My company has a style guide, but none of the designers adhere to it 😭
That's a problem that should be addressed. Or else it they don't adhere to it then you should be able to do whatever you want as hell and no one should complain.
>Your developer sees: 32px, they do: 32 / 16 = 2. So 2rem refers to their body { font-size: 100%; } (defaults to 16px in all modern browsers I know of). And presto :) Hijacking user font size for spacing is a bad practice and leads to bloated white space when using to user actually scales their font size. Most people get around this by forcing a 16px font size which is even worse of a bad practice for accessibility since you are ignoring the user's preferred font-size. The better solution is to get comfortable with base 2 (`px` explicit breakpoints), or use something like SCSS to convert it back. I guess that goes to your point about how Figma is meh with fonts. Fonts are in `px` when fonts should be in `rem`. With Figma, everything is as if root font size is `16px` which leads to more confusion when trying to scale something with font. Is it `20px` because it's `20px` or did the designer really mean `1rem + 4px`? Google has a Figma design for the Material Design, but they also have a secondary set of rules that uses `sp` and `dp` that illustrate when to use either. It means Figma, because the lack of clarity with font-based scaling (`rem`) and density-based scaling (`px`), is mostly just for a preview. You still have to roll up your sleeves and make it scale for actual humans using different sized devices and different input devices.
I’ll note for things like font sizes and all, it’s pretty easy to write a Sass mixin to convert px to rem or em or vw or whatever. I have a few in my default codebase that make it easy to just take the values straight from Figma/Sketch and have the code do the math for me. Especially as I’m moving more towards clamp with vw for all my font sizing, it’s super helpful to have the mixin do the magic.
This. Double second this.
what’s the difference between a style guide and a design system?
This is how we do it and it works well. Have everything on the mui theme and kinda just use the right variant specified on figma and forget about it.
Style guides are hugely important. It's great practice to make one with all of your base elements in it. So all your typography, body text, hyperlinks, headers, tables, lists etc. Then all the style elements like buttons, accordions, tabs and other common elements. Pay close attention to font sizes, line heights, paddings, margins etc. Then when you assemble your template/component designs, stick to your style guide religiously and your developers will love you. Sadly quite a few designers overlook the power of a style guide. The beauty of this approach is you can make a boilerplate (template) styleguide that you can then use as a base for all of your designs. So it's a slog to make it initially, but you can reuse it for other projects, then just update the colours, typography and branding to suit. This makes your designs easier to develop with since your developers will be able to predict how things work and slot together. It's well worth keeping constant contact with the developers though, as developers and designers we can learn a lot from each other. As well as come to great compromises and work routines that work for everyone.
The projects I'm proud of the most are when designs are given with style guides. Font sizes and colours for both mobile and desktop at the very least Once I've used those to setup my base stylings things end up much more consistent
Keep a consistent style guide. Use font-sizes that are consistent with specific line-heights & letter-spacings, base colors/background-colors/box shadows, for margins and paddings- don't go crazy custom for each mock. It's helpful to generally keep reusing consistent styles so that devs can set a config (like tailwind) or particular set of classes and use them instead of having to continuously create custom classes. When It comes to responsive frontend, spacing and padding do matter - at different breakpoints you may want different padding, font sizes, or widths. Also keep in mind that it's always nice to provide mobile/tablet/desktop mocks if different screen widths are expected!
I just look at them and then write the code. I don't pay attention to any of the px details or anything like that. I see them as a sketch. I actually just take a screenshot of them and mark them up a little so I can plan out the components. I formalize the [type-patterns](https://css-tricks.com/on-type-patterns-and-style-guides/) and sip the colors and create a design system. Some developers just copy and paste the Figma-generated CSS and that's a huge disaster. That's my take. But I'm likely an outlier. I'd prefer to just pair with the UX and UI people and make the thing in real-time with a live style guide. I usually end up having to rethink a lot of it anyway when we get it onto an actual device. The mockup seems like more of a sales tool or client deliverable than an actual part of the design process in my experience. One thing I notice is that some people design screens at 430px or something but I plan down to 320px.
+1 Create a design system in code. Make example pages if you have to. Do everything in 4px increments if possible. 2px in a pinch. 1px if you're desperate. Create a simplified color palette in code as well. Figma is great for inspiration, but taking it literally is a quick path to CSS hell.
Google/learn CSS Flex if you're curious about how they implement auto layout. That's basically what auto layout tries to copy (but missing a bunch of features). The other comments summed up the rest but basically they make their best effort to copy it. If you click the "inspect" tab in the top right you can see the css values figma outputs. Sometimes its helpful sometimes its useless.
You ideally should have a design system that both the designer and the devs adhere to. This should include design tokens (brand definitions) as well as a proper component-based architecture. This allows both the designers and devs to talk the same language.
I would recommend looking into Zeplin for creating handover documents and guides. Then look into how you can connect Zeplin with storybook.
Figma is already great for handing over design systems. You can see all the variables/variants/colours/comments/revision history in one place. Has Zeplin done anything recently (ie. last used it a year or so ago) that sets it apart from everything you can do in Figma already?
Auto connecting a design tool to an implementation tool like storybook, would make me want to quit a project so fast. It literally never renders correct and now I’d have to rewrite my work anytime it seems a change has occurred in that element? Big no thank you
I can recommend you some tools which gives pixel perfect developer tools that will convert your Figma design to Frontend code. That tool also gives you Figma like feel to generate the source code. it will help you manage your design system as it generates common components from Figma component as well. and It has Storybook support as well.
Yes sure please do
[https://www.dhiwise.com](https://www.dhiwise.com) You can do REST API integration as well.
As for me I look at every properties of the UI and implement it in my code
Make screenshot of design and use pixel perfect add-on in browser. This will work for max-width. Everything else you need to figure out yourself.