As a small studio, we need a way to automate as many tasks as possible. We needed a flexible system that can adapt to a variety of different brand expressions whilst still covering consistent rules about usability and accessibility.
We built our own design system and React component library, based on core principles of inclusion, usability, and flexibility.
Nautilus is still very much in-progress, but already it’s helped us get products and apps up and running much more efficiently than if we had to build them from scratch. Including Nautilus in our projects also means every project benefits from future improvements.
documentation, leadership, design-systems, visual-design, React, project management, accessibility, design-principles
As a small team, we needed a way to codify and document our practices, as well as avoid rebuilding the same components over and over again. We needed a design system and component library that was inclusive, usable, and flexible enough to allow for a wide range of brand expressions, but this didn’t exist in the open-source landscape. Many design systems failed to meet the usability and accessibility standards we hold ourselves accountable to.
Building our own design system allows us to establish a solid, predictable baseline for my work without needing to reinvent the wheel every time, allowing us more room for experimentation and innovation.
Our first step was to assess what we already had by looking at recent work. This audit revealed a consistent style—clarity, contrast, and boldness. This formed the basis for foundational guidelines, a type system, design tokens, as well as the components themselves.
Design principles are key to a design system. When used correctly and well established, they infuse and inform every other decision. It was important to establish these principles early into the process, since everything else derives from them. Via a series of post-it note exercises, we established a shared vision and a clear set of guiding principles to inform all work to come.
Nautilus provides a palette of seven hues, each with 10 tints and shades, balanced against a greyscale gradient to ensure predictable numerical contrast for accessibility purposes. It also provides a neutral palette of greys to match. Components check for adequate colour contrast to ensure accessibility.
Nautilus includes a flexible type system, including rules for calculating type scales and for programmatically determining an optimal line-height that would still fall on our baseline grid.
Semantic combinations for different “voices” and contexts forms the baseline of the type system. Type variables are themeable, as are the actual combinations of tokens into semantic styles, making for a highly flexible system with core rules.
Nautilus uses the popular
8px grid due to its flexibility and ease of use with icons and other elements. It also includes spacing variables and rules for how padding and margin is applied to elements. This leads to more harmonious visual layouts.
We build each component collaboratively, starting with research and documentation, and then building out the components in React and reviewing back and forth until everything is accessible, usable, and conforms to our standards.
We invest time in ensuring that everything is well-documented and a clear process has been established. We set milestones, prioritise tasks, and automate as much of the process, from testing to releases, as possible. Since the project is open-source, almost all of our work is publicly accessible to anyone who might be able to learn from us.
It’s still early days for Nautilus, but we have a strong vision for the future. Our plans include including React Native functionality, a Sketch or Figma library, brand tokens and themeability, automated theme generation, and an in-browser component playground.
Because it’s all open-source, the best way to keep tabs on our progression is to follow the project on GitHub.
Codifying our practices, defining guidelines, and thinking through things on an atomic level, and considering the semantics of all my decisions allows us to improve and validate our own skills. We’ve also laid the groundwork for better communication by creating a shared vocabulary and mental models. We’re both better equipped to make decisions without the other’s input.
Already, we can bootstrap a project quickly—and right out of the gate, what we have is already usable, accessible, and balanced.