Working with Nebula

Design Systems provide an evolving catalogue of design patterns which form the basis of a shared language enabling conversations about our user experiences. Nebula is a brand agnostic design system which defines these design patterns and allows brands to apply their theme to them.

Using these patterns allows designers and developers to have a shared language to create consistent experiences across multiple platforms with minimal effort. Any new and updated patterns can be usability tested and then added to the catalogue for everyone to use.

For designers

It’s about making sure we can effectively evolve our design patterns without reinventing the wheel. We want to follow the existing patterns where we can and make sure any improvements we make get fed back into the system so that everyone can benefit from them.

For developers

It’s about making sure we have a clear understanding of the intention of the designs, while baking in standards, for example, accessibility, and performance. It’s about being empowered to sense check any changes that might result in suspicious overrides to existing code.

Making changes in the right place

Usually, changes to the UI arise during design so this is the first opportunity to discuss them. Depending on your team’s workflow, this may already be a collaborative process which includes designers and engineers. Cross-discipline discussion helps everyone on the team to understand why and how these changes need to be made and flag any extra work or concerns.

In an ideal world, new experiences are created using established patterns, but what happens when they aren’t sufficient? Perhaps we need to get input from a user and there is no component defined for that yet, or maybe there is and we’ve noticed users have a hard time with it. Perhaps the current patterns aren’t up to date with the brand or we want to try something new that has yet to be defined.

The best place to start would be to ask yourself, does the pattern you need already exist? This isn’t just limited to the design system, reusing and updating components in your own codebase will also improve consistency.

If it already exists and does what you need

Go ahead and use it, this will create a consistent experience for all your users.

If it doesn’t exist or doesn’t cover your use case

Consider if it is a simple change (for example a bug fix, or an obvious improvement that doesn’t need usability testing), if so go ahead and update the pattern (check the contribution documentation for more details about how this works). If it’s something completely new or something which only really makes sense in your app then the best approach is usually to build what you need and put it in front of your users! If it turns out they love it, then it’s probably a great pattern and other teams could benefit from using it, contributing it to Nebula is a great way to share with other teams.

If your change is related to your brand

For example if you need to update a colour, or a font, then it may be more appropriate to update the theme rather than the design system itself. As the theme is shared across multiple apps your change will be applied in many places, make sure you let everyone know what your change is and why you made it.

Summary

The design system is here to provide a shared language and help give everyone a starting point for these conversations.

Building new experiences is a collaborative process, so if you make only one change to your team’s workflow, try having more conversations between designers and developers to make sure everyone is on the same page. When we have a shared understanding of what we are building we can more effectively create and share our efforts across multiple teams leading to a more consistent, better experience for everyone.