Role

Product Designer

Timeline

Oct 2023 – Present

Market

🇬🇧 UK

Stack

Figma, React, React Native

Website

Storybook

At Newcross, in addition to other projects, I helped build and implement the Halo design system, including creating documentation with real-world examples so designers and developers would have reference points in practical contexts and scenarios.

I've kept the system up to date and in line with latest Figma features, bridging the gap between design and development and so that everyone on the team can be more efficient.

Starting point

Our design system initially comprised a single library file, which served as a good starting point. However, as the library expanded, managing and tracking changes to components across the canvas became challenging. This monolithic structure proves difficult to scale in the long term and leads to frustration when attempting to locate specific components scattered throughout the canvas.

Adding to the confusion, we maintained two versions of components: one for the native app (React Native) and another for the web (React). These components frequently differed, with variations in props and structure.

Lastly, we didn't have a dedicated team to maintain the Figma library. Developers were working in a federated way, but things were often not in sync between the development and design teams.

Splitting the library

To make the system truly scalable, I was pushing to split the Figma libraries so we don't mix native app and web specific components (given some minor differences between the two). This would align us with how developers handle libraries and packages - making it a no-brainer. Finally, dedicating a page to each component will organise things and make it easier to locate a specific one.

Halo Design System library structure — I've split the Figma library, featuring two CORE libraries (tokens and icons), and the remaining two dedicated to app and web components.

Documentation process

With a federated approach in mind, I’ve designed the system to be lean and easy to maintain. The documentation for the components is meant to be concise and straightforward, as I don’t want the system to feel like a unnecessary overhead.

Here is an example of an avatar component, complete with its dedicated page, overview, and dos and don'ts. I have implemented a simple system for deprecating a component, ensuring that any changes or updates won't disrupt other designers' work

I've worked with elaborate design systems that had excessive documentation, which over time became unstructured and low-value. I favour simplicity, balancing between too much and too little (to save time and effort) – but again, this largely depends on factors such as the size of the project, team setup, and specific needs.

Anatomy and measurements of a component in Figma — One of the 'controversial' things I suggested was to drop the component’s anatomy/measurements in Figma. They can cause confusion and require constant updates. Devs can inspect all the properties (and tokens!) in Figma already, designers can check the component visually in the staging environment and use tools like Chromatic/Storybook.

In the end, it all boils down to keeping things simple but not too simple, finding the right balance between too much and too little (without creating extra work).

Snippet of how to use the halo design system — Here’s a snippet of ‘How to use this system’, explaining the process of marking components as work-in-progress, deprecated (among others).

Internal Figma documentation assets — All the internal documentation assets that I've built in Figma have proven to be enough.

Example of a changelog with it's dedicated page — Each library has a dedicated page with a changelog so that teams are kept up to date with all the updates. Additionally I'd slack the updates in our design system channel.

Component props example between Figma and Storybook — I've built components in such a way that they mirror the component props in code (okay, not 1:1 - there are some trade-offs here and there due to Figma limitations, but it's better than before!)

Figma tokens and variables — We were transitioning from the styles to tokens, I've built a token set, documented and explained the difference between the 'old' and new ways as well

A lifecycle of a component (from design to code)

A design system relies on having processes in place - nothing built in Figma matters until a component is built properly in code. Given the challenges of our federated set-up, we’ve huddled together (design and dev team) and created a Jira board to track the component lifecycle, from ideation/concept to code.

Screenshot of our Jira board, used to track the component lifecycle — I've built and maintain the Jira board specific to the design system. It went through some iterations so that it can suit both the design and dev team (with two separate backlogs). The dev team usually picks the ticket in their sprint sessions (based on blockers/priorities). We also have weekly huddles to update everyone on the design system updates.

Figma tokens and variables built into the component — I've baked in all the tokens/variables into the components from the beginning.

Re-usability and flexibility

The system had to be flexible to some extent, of course. I've built it with reusability in mind (as it should be!), introducing and explaining the slots concept so that other designers can leverage it.

Slot component re-used in other components for flexibility — Slot component and it's concept explained.

App bottom sheet was one of the components that benefited from slot.

Writing in progress...