The context
When I started at Hireup, the design system had not been updated in some time. There had been a number of passionate designers and engineers contributing to it in the early days however they had all left by the time I arrived. The design system didn't have an owner, and we had no resources dedicated to maintaining it. It was time to muck in and revive this old dog!
Establishing processes and getting buy-in
In large organisations, a healthy design system requires a healthy amount of discipline, especially when there aren’t dedicated caretakers.
One of my early initiatives was to document a process for introducing a new component or pattern into the design system. This process had two phases, one from a designer’s perspective, and the second, from an engineering perspective.
Foundational tokens
Typography, colours, and foundational spacing and sizing tokens were mirrored in Figma and Storybook.
Building foundational components and patterns
There were a number of foundational elements established in the early days of the Hireup design system, however, there was very little guidance written and a significant number of missing essential components and patterns as well.
Our approach was pragmatic: we added new components and patterns as we needed them. When a new feature or flow required a new component or pattern, we used that opportunity to introduce something new to the design system.
Working in Storybook
The source of truth for the components existed in Storybook, a code based component library. I documented the use of components here and along engineers added components and maintained existing ones.
Cursor and AI-assisted design system workflows
Cursor as a design tool has created new opportunities and accelerated workflows!
Prototyping in code
With the introduction of Cursor, I started to prototype new components directly into our production code base. Cursor already has existing context of both our component library and web app repo, and progress was made with low effort.
The old way, an elongated process of designing a component in Figma to then import it into the code base with various checkpoints along the way all of a sudden felt compressed, or better yet, optimised.
Working code-first feels natural, and far more efficient.
Pairing with agents to analyse code and document patterns
I started to explore using Cursor as a collaborator for developing design system guidance. Cursor has the ability to read our entire codebase, and with an appropriate model selected, was able to analyse use cases and develop themes within current component use.
I created a design system guidance framework, which the model was then able to follow and populate to provide decent first draft guidance.
Initial prompt (paraphrased):
Here is a link to the Design System guidance framework, and a link to our existing button guidance as an example to follow. I want to develop guidance for the Dialog component, and in the process theme, the ways we are using the dialog into a few consistent groups. For example, one common use is a confirmation dialog to verify a destructive or significant action before it is carried out. Do you need any other context to begin?
Again, this supercharged the process of retroactively developing design system guidance from an existing, and at times ambiguous code base.
Summary
Real talk: Establishing solid foundations, processes and ownership are critical to the longevity and utility of a design system. Adding a new component without also providing guidelines for the team or agents on how to use it is only doing half the job. A component without guidance can easily contribute to the chaos, rather than removing it.