Overall, the team agreed that designing with the new system is more productive. We observed an average 30% increase in productivity, with designs being built and finalised from scratch in as quick as just one working day. For project-based agencies and freelancers we collaborated with, having a master design system ensures alignment on the same language, and it can be utilised to develop a product-specific design system, e.g. Mobile app. This aids in managing components and tokens that are platform-specific, e.g. Android and iOS, on a scalable approach. Despite these benefits, we also noticed some issues and areas for improvement:
Some definitions and applications are not clear
It was the team's first attempt at creating a design system. Although we consulted various design system documentation to assist in creating ours, we acknowledge that some of our definitions and guidelines may be unclear or not applicable in practical use cases. For instance, our grid is not consistently scalable in responsive layouts, as initially indicated.
Some core design foundations are missing
Certain foundational tokens are either missing or not clearly defined to encompass all the specified use cases in our designs. One of the most impactful examples is the absence of a container size definition. Consequently, as we continue to build pages on different platforms, developers may at times need to calculate the width of an element on screen by percentage, leading to random and inconsistent container sizes in our designs.
Lack of usable templates and components on Figma
As we rushed to build the design system, a mistake occurred: we forgot to construct components as variants and provide users (designers) the ability to customise these components by properties. While this oversight does not impact development, it may cause confusion, as designers might resort to creating their custom variants when they are not able to locate them on Figma.
