Why have a design system?

#css #design #designsystem #webdev

A very common thought when we talk about technology "This takes a long time so I shouldn't do it" if you read this article, You know that many "laborious" things become valuable in the long run.

A design system ends up becoming essential as your code base grows, imagine your entire system interface as a big puzzle. If all of this isn't "organized" with each piece you add, it makes maintaining your system more difficult. Think that you took a long time without needing to add some CSS property to a component and after some time you need to do it, the chance of you taking a long time to find your component and even your interface starts to "balance" because of the additional CSS is very high.

CSS is powerful, but we have to be very careful when using it, we don't want to spend minutes or hours giving "1px solid red" to find out where our problem is. Below is an example of the noise that additional CSS can cause in the interface.

If we have a component A and we add an extra property to it, it can change the composition of the layout and several components can be harmed. Which would take longer for everything to return to normal.

If each component is like a domino ready to knock the others down, just organize the table where they are.

Monorepo

Use a Monorepo It's a way to have our code shared across multiple projects. We'll use this example to explain how a design system works. Generally the shared code for UI is in package/ui. You can change it if you prefer.

Standardizing your code prevents it from being too difficult to maintain your system, so we'll take all the smallest components and start our design system.

Forms, Inputs, Buttons, Tables and any other component that is repeated a lot during the application can become part of the design system.

const Button = ({ text = '', isSubmitting }) => {
   return (
     <Button disabled={isSubmitting}>
       {isSubmitting ? <Spinner /> : text}
     </Button>
   ) 
}
export default Button;

Radix UI

Using a library with components is very useful for building a design system, as its components have accessibility and a small defined pattern that can be easily extended.

And there are also primitives that are components without styling with some behavior, e.g. Drawer, Dialog components, etc. There are several options, choose the ones that make sense for your application.

Design pattern

If we put all our components together and they were all without a defined pattern, it would be a disaster. A design system should solve this problem.

The idea is to have a practically immutable base and just extend it (if necessary), this avoids the noise of adding more css.

Docs

Storybook is a great tool for us to see all of our components, such as their variations and descriptions. This can be extremely useful for your team.

Conclusion

I'm seeing a lot of things about design patterns and I'm migrating a design system to Radix UI, it's challenging, but it helps a lot to understand the process behind it and the importance of having a design system.

Thumb by Ryoji Iwata on Unsplash