A UI Component Library for Designers and Engineers to accelerate Product Design and act as the backbone to a unified suite of products.
Pick Your Flavour: Vector or Code?
Helix is accessible to all and fun to use.
We built Helix to be beautiful, compliant, easily composable, and scalable. And we serve it in two “flavours”: Figma and React. A dedicated UX Designer and two frontend Engineers maintain our library. So regardless of which library someone’s working with, they always get the latest updates. Designers receive a prompt within Figma that updates are available. Meanwhile, a dedicated Teams channel serves as a place for getting updates and requesting help with Helix.
When creating the infrastructures for those who would be working with Helix, we intentionally turned our “UX” skills inward. We took feedback from designers, engineers, and others so that we could craft something easy and enjoyable for everyone to work with.
Established UI Patterns
We do have a few rules…
Beyond having a set of components that have a cohesive look and feel, I also wanted to standardize on common UI patterns. This gives our platform users a reliable and predictable experience. Plus, there’s less re-inventing the wheel for our designers. Our engineers now have an easier way to replicate similar UI scenarios, which is frequent within enterprise product design. The UI Patterns are published within the Helix’s documentation so anyone can reference them easily. They even come with copy-and-paste code examples!
Modern, Composable, Plug-and-Play Design
Helix Components can be quite small or surprisingly large; but they are designed to nest, stack, & “Play Nice” together.
We designed our individual components to work together well by standardizing things like spacing, typography, padding, border-radius, shadows, and colour palette. In Figma, these attributes are conveniently stored in the properties panel. Component variations are just a dropdown menu click away. We’ve also happily jumped into some of Figma’s latest beta release features (which I’m a huge fan of), including variables, conditional statement prototyping, and dev mode.
In the code version of Helix, we have a library of utility class names that can be added to any element on the page. To avoid conflicting with other code, all our class names are prefixed with “helix-“. So applications can pull in a single component, or many, without worrying about style conflicts from our library. We also use the Styled Component methodology to dramatically reduce Helix’s impact on load time. Only the react components actively being called, plus its specifically defined properties will be pulled into the application when it’s building.
What’s Next for Helix?
Designs Systems are like a garden: they need to be maintained, pruned, and added to. Helix is already thriving and has more contributors (and users!) than I could have dreamed. However, some things on the horizon will make our component library even better. Such as increasing publisher awareness when we release a new component. And making it even easier for engineers to access “add-on” utility class names.