We laid down the foundations of the design system for our web app platform, to make our workflows more efficient and to provide everyone in the team with a common design language to use when talking about the different aspects of our product.
Context and concerns
We were thinking of ways to improve and make our process of creating mockup designs more efficient in the long run, because as it stood, it would take a few weeks before a full-fledged mockup for a particular feature was finished, including the application of feedback.
We then worked towards creating a design system that will be contributed to by everyone in the Product Team, which includes designers and engineers, as a shared living document of all the elements found within the AcadArena web app. This would serve as the common design language used across discussions for feature requests.
We made full use of Figma’s facility to have component sets, variants, and even component properties to make sure that things are ready as they are if to be used in other contexts. We also used the Figma plugin Tokens Studio (formerly known as Figma Tokens) to document the different properties of the elements in our product, to connect our designs with the development process.
Snippets
Top: Guidelines for naming Design Tokens. The reason behind this naming convention was to focus on the utility of the token first so that it would be easier to group and find variants within the context of that element. If there was a need to make a desktop- and mobile-specific style (e.g. font sizes for headings), then the token and its variants can be appended with .desktop or .mobile depending on the need.
Bottom: Size Scale for naming component variants or styles. Based on TailwindCSS’s own size scale, to put everyone on the same page when naming sizes.
This is a preview of how the Color Styles were laid out visually to easily identify groups and purpose. Each of the values for the color token blocks—from the color shown in the box to the labeled values—were all set via Tokens Studio, so that if ever there was an update to any token defined here, it would be easy to update the documentation.
Top: Breakpoints defined with gray frames, for easier copy-pasting or resizing based on the needed viewport. Breakpoints were based on TailwindCSS’s breakpoints documentation.
Bottom Left: Spacing Guidelines for grouped components used in the design system. Values themselves are referenced from TailwindCSS, and the visual documentation was set up with the help of Tokens Studio. Each of the rows in the Spacing table is also set as a spacing token in our saved configuration.
Bottom Right: Default Page Spacing guidelines for certain page layouts. Annotations were added to add further explanation to specific parts of the layout, mostly for dev implementation guides.
A preview of the properties panel for the Button component set.
A preview of the Buttons component set used within our web app. The label and icon are both easily overridable values and can be seen in the component properties panel when editing the particular component variant.
A snippet of the different components in the Forms section of the Design System. Building Blocks were first defined and were used for all Field Components, which are all nested components that are responsive and fluid in setup.
The Sample Field Blocks section serves as a playground and also a base reference for the usual components found within the web app. We decided against defining these as components in themselves because we wanted to still have that fluidity when setting up the particular components in this section.
Snippet of the Navigation page of the Design System, showcasing the building blocks for the sidebar navigation, header, and footer components used throughout the web app.
