design tokens, component library, documentation, governance
Ocean is Blu's design system, an ecosystem of components created to redesign all Blu interfaces and solve product inconsistencies. It also provides scalability and agility to the design and technology teams.
About 3 years ago I had the opportunity to help bring a Design System to life, and today, as Design System & Ops Lead at Blu, I am the person responsible for governing and maintaining it.
Our design system is collaborative, but I mainly work on my own as a one-person team, alongside the developers.
a project made by many hands
To bring this project to life, we partnered with a consultancy. Their guidance was crucial in helping us understand where to begin and how to move forward.
It was wonderful to be part of this process from the very beginning. Although the consulting period was brief, I learned a lot from it. It also gave me the knowledge I needed to keep working on and developing Ocean up to this point.
As the Design System & Ops Lead in the design team, I take charge of creating and documenting new components. I also work closely with the technology team (web and app) to validate ideas and coded components, engaging in productive discussions to address issues and make necessary adjustments. Today, I am proud to be leading the way towards a more cohesive and effective design system.
To start Ocean, we first mapped out all the interfaces. This helped us identify areas that required fixing and improvement.
Also, we put together a list of the components that showed up repeatedly in different ways. One of the most interesting things we discovered was the huge range of types of buttons, sometimes even on the same screen 😅.
Once we'd spent a few days working on the inventory, we began crafting concept screens. These were basically mock-ups of interfaces that closely resembled what we wanted for our products.
From these screens, we were able to identify the key components that would be used across most or all Blu products: things like buttons, input fields, radio buttons, checkboxes, alerts, tags, and more. These became our Core Components.
Ocean has additional layers of components, including Team Components, Blu Components, and Exceptions. More on that later ;)
In this stage, we also created our design tokens. However, we continue to evolve them to this day by making a few tweaks and removing unnecessary elements.
structure and layers
A design system can include everything from product visuals and tone of voice guidelines, to the construction of processes and documentation. These layers will be tailored to the needs and maturity of the company, and can be adjusted along the way.
Currently, at Ocean, there are five layers, from bottom to top: foundation, components, patterns, pages and flows, and products.
In this layer, the foundation for all product elements and flows, as well as other materials, is defined. This section contains definitions for grid and breaking points, design tokens, motion tokens, icons, photography and illustration styles, tone and voice guidelines, and other related information. There is no defined structure for this layer, and the number of items within it will vary according to the need.
Our design tokens guide the construction of everything we create for Blu's products. However, there is still room for improvement, and we are continuously working to evolve them.
Currently we have mostly the basic Design Tokens: colors, typography, spacings, border radius, and a few more.
Ocean's icon set is composed of a combination of the Heroicons library and custom-made icons (Blu Icons). In Ocean, iconography should only be used purposefully to support information.
At first, it was a challenge to understand how we could create layers of components according to their purpose. As Ocean is an open-source design system, we couldn't leave components with Blu's business rules and details open to the public. Additionally, there were specific components for each squad or that would only be used in a single flow.
After some studies, we arrived at the structure we have today, where the components are divided into four groups:
Generic components, common to several or all squads and that do not depend on specific business content to exist. These components can be in the open source part of Ocean, since they can be reused in other projects without major problems.
Specific components in flows of a certain squad. They do not need to be generic or reused by other squads.
If it is identified that a team component is being used by other teams, it may be promoted and become part of the Core Components library.
Very specific components to Blu's business that contain embedded business rules. They are not part of the open source portion.
Exceptions are components that are not reused outside of their first use case. They are usually very specific to a functionality and do not need to exist in other layers of Ocean DS. Similar to "snowflakes" in Atomic Design.
hand-off to development team
Once the design step is complete, the component is handed over to the development team with all the necessary specifications.
When they have any doubts, I help them, and in the end, I approve the component via Github or Chromatic. It's a partnership.
Besides taking care of all the visual aspects of our Design System, I also document best practices and processes to Ocean. This includes processes for reviewing new elements and adjustments with developers, as well as analyzing the need to create a new component instead of using an existing one with designers.
Also, I make sure everything in Figma is well-organized and properly built. As Marie Kondo taught us, I like to keep it tidy!
If you are interested in learning more about my processes, please feel free to get in touch with me. :)