SPACE Design System

Expanding the design system capabilities of the design and engineering teams was my core focus during my time at Enboarder.

Background
An audit of the existing library told me that it was chaos in the Admin platform, and non-existent in the End-User platform. 1 button had become 6 buttons, menus were no longer menus, and the origins of “GreatBigSearchBar” are still a mystery.

We called the new system Space, and I led our squad (Space Council) through the whole journey from leadership buy-in, to roadmap delivery, to implementation.

Build & Design
I worked side-by-side (figuratively and literally) my main engineering partner during both design and build of each component. The collaboration between us was key to maintaining the integrity of the system.

I consulted with both engineers and our design team before finalising the structure and naming convention of our design tokens. (Won’t lie, we didn’t get it right the first time!)

During the design process, I ran the skeleton components past our designers before finalising anything, ensuring that all their feedback was captured before it went to build.

After the core set of components were ready, I held several training sessions during which I went through the design of each component, demonstrated how it had been structured in Figma, along with a run through of the component documentation that I had written.

Implementation
When we first started building Space, I was also the UI designer for another squad. Since they had not used any of the pre-existing components, there was the opportunity to design any new features with Space. This allowed me to gain real-time insights as I was building components tandem, making adjustments along the way.

I worked with the leads of each squad to develop implementation strategies, as adoption levels and capabilities would vary due to feature complexity and resourcing, and everyone from designers to engineers to PMs was excited to finally have some way of ensuring consistency in both code and design.

Process
What does governance look like? Who should contribute? How do bugs get reported?
Understanding that every design system team is different due to aspects like resource and skillsets, I proposed that after we get implementation off the ground, our team takes the primary role of guidance and governance, bug fixes, feature requests; while creating new components would rely on all designers and engineers to participate through a contribution model. All proposals pass a checklist which measures against effort, impact, feasibility, and roadmap.

Creating Enboarder’s design system was highly detailed, highly collaborative, and ultimately highly rewarding.