3 / S C
When we think of design systems, large and complex examples like Adobe Spectrum or Shopify Polaris often come to mind. These systems serve vast teams and complex ecosystems, making them appear out of reach for smaller teams or simpler projects. However, even at a smaller scale, a design system can still provide a strong foundation, improve efficiency, and enhance consistency across products.
In this article, I’ll share how we helped our regular collaborators, Able, create a design system for their Apex e-commerce platform’s admin portal.
Able approached us to help them with a design system that could scale as their product grows. This was an exciting opportunity as this helped us validate our efforts to create MVP design systems and also gave us an opportunity to collaborate on code components.
Prioritizing what’s important
The main challenge was the short two week timeline for phase 1 of this project. Fortunately, having been involved in the design of the product's initial version, I was already familiar with its structure. This, combined with our previous experience, made the timeline manageable.
However the short timeline we had to clearly prioritise what we wanted to achieve. After discussing with product, design and engineering, we established the following priorities for phase one:
- Build components that are essential and add the most value.
- Decide on how we approach theming.
examples of theming
We decided to restrict theming to certain interactive elements during the first phase. More customisation options such as dark mode, radii, typeface etc were scheduled for future phases.
Colours and variables
Our guiding principle from the beginning was to create a variable structure that was both easy to use and maintain.
With current and future theming goals in mind, we audited colours from the completed designs and initially categorised colours into four buckets.
- Neutrals colours: These are greys, used for background surfaces, text, inputs borders etc
- Primary colours: Used for certain interactive elements like buttons, switches, tabs etc. These would support basic theming mentioned before.
- Special colours: Used for specific elements like tags, status etc.
- Feedback colours: Used to convey success, danger, warning and info messages, destructive actions etc.
After the audit, we defined three collections Primitives, Special and Semantic colours.
Primitive colours: Traditionally primitive colours are named without any semantic meaning (greys, blues, reds etc). We instead chose to take a semi-semantic approach to naming them. We went with greys, theme, success, warning, danger, info and translucent. We chose this approach because it was easier to support theming.
Special colours: As mentioned above, these colours would be used in one-off components. We separated these out so that they would not accidentally used elsewhere in the app.
Semantic colours: Initially we started out grouping these variables as neutral, interactive with background, text and border subgroups. This approach however proved more complicated and confusion. For example, a tab is an interactive element but still uses the neutral background. So instead we with a simpler grouping of background, text and border.
some of the semantic colour variables
Interactive states
Rather than defining new colours for interactive states (hover, active, etc.), we layered state modifiers on top of default states. This approach kept the color palette more manageable while supporting all necessary states.
interactive states using modifiers
Numbers and typography variables
We created a separate collections for typography variables and turned created type styles using these variables. Our number variables were kept intentionally simple, defining semi-semantic categories such as radius, spacing, stroke sizes, and component dimensions. Adding further granularity didn’t offer clear benefits at this stage of the project.
Documenting components
Given the tight timelines, we had to be very efficient in documentation. We used consistent emoji to clearly convey component properties and documented these.
component legend
guide to colour variable names
For more complex components like tables we created more detailed guide on how to use them inside Figma.
guide to using a table component
Conclusion
This design system was built with ease of use and scalability in mind, providing a strong foundation that could evolve and grow as the Able’s products evolve and grow. While working closely with developers on this project we were able to better understand how code components are built. We look forward to helping more teams leverage the benefits of design systems.
