Multi-brand design system
Hydra Design System
Neudesic's application Hydra, a design system used for sales acceleration lacked proper file structure, token support, and multi-brand support, leading to long turn around times and development rework.
A redesign of the Figma file ecosystem, design token implementation and JSON file export workflow, documentation, and foundation & component libraries that can scale for multi-brand sales pursuits.
Redesigning Hydra led to the following:
The company (Neudesic) could now participate in more RFPs, and more robust sales pursuits because designers now had the tools to scale quickly.
Developers now have dev ready assets for multiple frameworks including React, Flutter, SwiftUI, Maui, and Kotlin. Future frameworks can be easily be added.
With the addition of of a domain component level file, designers can tailor components to match a brand's design quickly, while still getting updates from the core component libraries.
The design system can continue to grow and evolve because a managable structure and robust documentation is in place.
The original Hydra Structure consisted of a foundation file and component file. Developers used their best judgement to build designs but had no documented components or patterns. Many basic UI components were missing, there was no support for variables or tokens, and it could not be scaled beyond light and dark modes.
For Hydra to meet the Stakeholder's business needs, a scalable/repeatable structure was needed that any designer or developer within the company could use.
With this structure, designs will come with design tokens attached. Developers can export the accompanying theme file as a JSON file.
Designers and Product teams could now design with their brand theming (color, typography, etc.) by creating a brand specific foundation file and a Domain Component file.
As part of the redesigned system structure is the addition of a 'Domain Components' file. This allowed designers to pull in just components they need, nest the base component into their component and restyle as needed. This solves the problem of using Figma modes for different brands (modes have a finite limit). As the design system evolves, so will any brand components attached.
This approach works but is certainly not perfect. It is contingent on the brand designer knowing how to build and manage their own component file. The brand's foundation file also needs to be complete prior to this step.
Because Hydra supports multiple frameworks (including React, Flutter, SwiftUI, Maui, and Kotlin), implementing design tokens was critical to maintain (and increase) the time-to-market.
Design tokens can utilize up to five (or six) layers to their naming structure. However, because of the broad use case for Hydra and multi platforms, that would not work for Hydra. As a team we workshopped several naming conventions and landed on Sass based structure that takes a lot of inspiration from Material Design and Amazon Cloudscape, while leaving room for additional hierarchical additions if necessary.
I created the Figma Variable Libraries based on the tokens needed. The focus was on comprehension and ease of use for designers and product teams and understandability and exportability for developers.
A key part of building variables in Figma was that developers would be able to easily export them to suit their needs. Lot's of plugins / trial and error got us to the right solution.
Critical to any design system is the accompanying documentation. To be accessible to a wide range of users, it needed to be quickly and easily consumable. Simple description and use cases and well formatted technical specs were key. In the future there are plans to implement this insto Storybook.
To create the most robust technical specifications quickly. I utilized the EightShapes Specs plugin.
Design token documentation needed to be findable and easily linkable.
Examples of components and their properties that I built as part of the Hydra Design System.
