4 ms·

Design systems that UI designers come up with can be baked into the utility css stylesheet in advance, before devs or other designers access it through html. Ki

Design systems that UI designers come up with can be baked into the utility css stylesheet in advance, before devs or other designers access it through html. Kinda like a living style guide, but in code. That's really the point, the css stylesheet is basically an intermediary step and single source of truth for the styles in the design. Then when stuff is being built devs don't have to think about styling, only layout and applying the correct values that are predefined in the css. That said, if you're on your own, have your own boilerplate and design skills that you can apply in real time and know css/html, you might be better off with regular css.

dsego 7y ago
Design systems that UI designers come up with... and then break them later every chance they get, because unlike what developers believe, design is not always lego blocks and styles will be tweaked to fit the context. A developer sees the sum of all UI components on a page, but the designer sees missing accents or not enough spacing and will adjust those to fix issues or achieve a particular look... the result being new styles for that page.
- csande17 7y ago
  +1. A lot of design systems assume that, for instance, there are only a few amounts of vertical padding you'll ever want to have on an element. But sometimes, the designer really will tell you that something needs 10 pixels of padding, your 8-pixel "p-2" value is too small, and your 12-pixel "p-3" value is too large.
  - rudiv 7y ago
    This is why I really like tailwinds, because for all the dynamically generated classes (90% of their utility classes) you can choose to use their scale (1unit=0.25rem) or just switch them all wholesale to a smaller increment so that when you need more specificity it's there.
  - harimau777 7y ago
    The problem that I see is that by making the decision that something needs to be pixel perfect the designer is often "volunteering" the engineer for an hour or more of fighting with CSS. In my experience the engineer is then expected to spend that time in addition to their normal workload. The only ways I can see it working are either: - Designers are obligated to follow the DLS. - Any divergence from the DLS is pointed and therefore takes away from the number of points the engineer commits to for other tasks during a sprint.
  - deleted 7y ago
    [deleted]
- deltron3030 7y ago
  That's the designers fault then. Most alignment issues are caused by fonts and their bounding boxes that are based on line height (fonts have a default line height they ship with). One of the errors I often see is that designers define font sizes based on the letter sizes, not based on their bounding boxes or how well they fit into the bounding boxes that should match the defined component sizes within their design system. Design systems have spacing scales, and fonts (and their bounding boxes) should be part of it.
  - mattacular 7y ago
    I wish you lots of luck in finding these mythical designers out there to work with throughout your entire web development career. You can spend plenty of time thinking of how things ought to be but the flexibility of CSS and HTML will always be utilized in real world applications where it's practical. Asking for a few more iterations from the design team to make their concepts fit your teams existing set of baked utility classes or even their own style guide (issued more than a few months ago) instead of simply writing a few more lines of CSS is not a good trade off in the eyes of most everybody including many developers.
    - deltron3030 7y ago
      The design team is responsible for the baked in utility classes in that case, therefore I don't really understand your point.
      - mattacular 7y ago
        My point is design teams that do CSS are rare. I've actually never heard of this unless it's a designer who is now working as a developer, on a development teams.
        harimau777 7y ago
        I agree that most design teams are not going to actually write CSS. However, it seems reasonable to me to expect them to organize and communicate their design in terms of classes. I see two advantages to that approach: - It requires the design team to take responsibility for structuring the design. E.g. determining parts of the UI that share the same design and defining a hierarchy of design elements. - It makes the work that the design team is creating for the engineers more transparent. Communication can be something like "this new wireframe requires 5 new classes" rather than something vague like "just tweak the styles we used for the other components to fit this new wireframe".

dsego 7y ago

Design systems that UI designers come up with... and then break them later every chance they get, because unlike what developers believe, design is not always lego blocks and styles will be tweaked to fit the context. A developer sees the sum of all UI components on a page, but the designer sees missing accents or not enough spacing and will adjust those to fix issues or achieve a particular look... the result being new styles for that page.

csande17 7y ago
+1. A lot of design systems assume that, for instance, there are only a few amounts of vertical padding you'll ever want to have on an element. But sometimes, the designer really will tell you that something needs 10 pixels of padding, your 8-pixel "p-2" value is too small, and your 12-pixel "p-3" value is too large.
- rudiv 7y ago
  This is why I really like tailwinds, because for all the dynamically generated classes (90% of their utility classes) you can choose to use their scale (1unit=0.25rem) or just switch them all wholesale to a smaller increment so that when you need more specificity it's there.
- harimau777 7y ago
  The problem that I see is that by making the decision that something needs to be pixel perfect the designer is often "volunteering" the engineer for an hour or more of fighting with CSS. In my experience the engineer is then expected to spend that time in addition to their normal workload. The only ways I can see it working are either: - Designers are obligated to follow the DLS. - Any divergence from the DLS is pointed and therefore takes away from the number of points the engineer commits to for other tasks during a sprint.
- deleted 7y ago
  [deleted]
deltron3030 7y ago
That's the designers fault then. Most alignment issues are caused by fonts and their bounding boxes that are based on line height (fonts have a default line height they ship with). One of the errors I often see is that designers define font sizes based on the letter sizes, not based on their bounding boxes or how well they fit into the bounding boxes that should match the defined component sizes within their design system. Design systems have spacing scales, and fonts (and their bounding boxes) should be part of it.
- mattacular 7y ago
  I wish you lots of luck in finding these mythical designers out there to work with throughout your entire web development career. You can spend plenty of time thinking of how things ought to be but the flexibility of CSS and HTML will always be utilized in real world applications where it's practical. Asking for a few more iterations from the design team to make their concepts fit your teams existing set of baked utility classes or even their own style guide (issued more than a few months ago) instead of simply writing a few more lines of CSS is not a good trade off in the eyes of most everybody including many developers.
  - deltron3030 7y ago
    The design team is responsible for the baked in utility classes in that case, therefore I don't really understand your point.
    - mattacular 7y ago
      My point is design teams that do CSS are rare. I've actually never heard of this unless it's a designer who is now working as a developer, on a development teams.
      - harimau777 7y ago
        I agree that most design teams are not going to actually write CSS. However, it seems reasonable to me to expect them to organize and communicate their design in terms of classes. I see two advantages to that approach: - It requires the design team to take responsibility for structuring the design. E.g. determining parts of the UI that share the same design and defining a hierarchy of design elements. - It makes the work that the design team is creating for the engineers more transparent. Communication can be something like "this new wireframe requires 5 new classes" rather than something vague like "just tweak the styles we used for the other components to fit this new wireframe".