I have been working with a design team that is trying to standardise a design system for the product we are working on now. In this article I have gathered some points that I think is important to have from the experience I have got working with one. Having said that, we may apply these points in future for the design system we have now.
A gold standard for a well designed design system and implementation
I believe, in the grand scheme of things, we should be at a point, where when we see a mock up page, we can clearly state what design system components are being used. A developer who needs to implement a page should be able to just use the implemented component for the page. Design system should makes everyone lives easier and happy not difficult; mainly designers + developers + product owners.
Layout components
Generally in an application there would be few types of layouts that all the pages are created on. A design system should have it’s own definition of what type of layouts that needs to defined for the application design. Layout is critical as that is a core component where we would place our other components. In a good implementation, we would even need to consider how the layout would re-arrange itself depending on screen sizes.
e.g. Layout components from popular design systems
- https://ant.design/components/layout
- https://mui.com/material-ui/react-box/
- https://chakra-ui.com/docs/components/box
Consistent states for all form input components
Each input component can have different states. We would need to clearly define them in design system in terms of how they are to be behave/rendered and have it implemented in your front-end components.
The states for example are:
- default
- disabled
- error
- focused
Design system components need to define variants clearly
In our design system, most input components’ label appears to be placed above the input field. However there are other variants noticed such as label placed on left side.
From an implementation point of view, this can be considered as a style attribute of the input field, and make this style available for all the input fields. On the other hand, if labels were always meant to be put above input fields, then in mockups we shouldn’t have alternative approaches because then we are not following the design system.
Another example is to have bold labels for inputs. For example in one of the mock up pages, we had some input labels in bold. But in design system, this variant is not present. We have to define the style variants in design system first, for consistency and have them implemented. This way we are certain we are sticking to design system practices not moving away from it.
Container components
Currently we only have one container design system component called Card. However if there are other type of containers that we are going to use in a mock up, then we need to ensure that we have defined them design system and have them implemented.
Spacing of components
Spacing (padding + margin) should be build into design system components. So we have to clearly define how the spacing amounts are. Then implement them in React component using appropriate CSS styling.
Therefore as a developer using the design component, we don’t have to think about the spacing. It should just render as expected.
If we are spending development time checking padding and spacing difference of elements in the mock up and adjust spacing with CSS, it’s heavily time consuming, and costly (regards to developer time) and clearly indicates a problem with our design system approach.
At the same time, when designing mock ups, we should not have to worry about perfectly placing elements in mock up. If the implemented design system components adhere to spacing guidelines, then spacing in the mock up should be irrelevant, making designer’s life easier also.
The need of a “Loading” design components and states
The nature of front-end components using popular frameworks like React is that the interactivity is dynamic and asynchronous. Meaning that it’s completely possible that a page finish loading but then dynamically the other parts of the page renders in browser page.
This can lead to confusion for a user with slow internet connection as they might stare into blank UI spaces in the page without any apparent indication that content is being loaded and rendered.
For this it would be ideal to have a general spinner component in design system that renders the loading state of a UI component.
e.g. React Spinners
The same can said for buttons as well. For example a React form submission by clicking on a button currently doesn’t reflect the background form submission that is happening. Here we could render a disable button but also have a loading indicator in the button.
Use props to specify style/behavior attribute of a design system component in React
Don’t allow to use CSS class names in React design system components. This is leaky abstraction. As a developer we don’t want to worry about specific CSS class names while using a design system component. It adds extra complexity. Instead use props as the interface for the component to change its specific style and behavior.
There might be exceptional situation, however this shouldn’t be the norm, and trying to avoid these situations so to be consistent with design system should be paramount.
Place to showcase live examples of implemented design system components
We currently don’t have any examples on using the implement React design system components. Currently the plan is to update the Design System Development Planning doc to put React code examples but it’s not scalable.
A more viable option would be to use a tool like Storybook: Frontend workshop for UI development . With this tool we can specify style and behavior of components and then in Storybook you can play with the attributes and see changes in real time. As a designer then they can also test out the design system component implementation in isolation. For a developer, they can quickly generate/find the example code.