Learn about Nebula and the problems it can help solve.
Nebula is a design system consisting of a set of connected patterns and shared practices. This means that Nebula is not only opinionated about how components and their interactions should be built, but also about how we create, define and share those things.
Nebula is made up of several elements; foundations, components, theming and guides.
One of the most tangible things that Nebula provides for teams is a catalogue of components and design patterns across multiple platforms (Figma, React and React Native). The aim of this catalogue is to provide teams with a central repository of components which have been built with accessibility in mind and are backed up by user research, which they can use to build out their different user interfaces. There are several advantages to working with a centralised catalogue of components including;
- Teams spend less time recreating patterns and components meaning that they can spend their time focusing on solving customer focused problems,
- Having a central set of components means that different UIs have a consistent look and feel across products and platforms for our users making them easier to use,
- Designers and Developers have a shared language and set of tools to use,
- Components are backed up by user research and have been built to AA accessibility standards, which means that every team can build high quality UIs without having to duplicate work.
- Nebula components are brand agnostic and when used alongside theme files different brand’s identities can be applied to them. This means that they can be used across different brands and platforms.
Foundational elements encompass the building blocks of a UI. These include primitive elements such as typography, colour, spacing and layout which can be combined into components. These are defined using design tokens in the branded and unbranded theme files and changing their values will change the overall look and feel of a brand.
Nebula is a brand agnostic design system, and this means that the components have been built without reference to a particular brand. This way we can use Nebula components across many different products, and regardless of how a particular brand defines itself Nebula components will always behave in the same way. In order to apply a particular brand’s identity to the components we use a theme file. Theme files for different brands are each owned by teams working within that particular brand. This set up means that the people who work with the theme the most have direct control over any changes they might need to make.
Guides are where we discuss how to create, define and share Nebula. These are a diverse set of opinionated guidelines on best practices for using Nebula, whether this is for building UIs with accessibility in mind, guidelines for building forms, or how to use Nebula to improve collaboration within a team. These guides and practises are constantly evolving and are intentionally more abstract than the component documentation. This is this section that distinguishes a design system from a component library.