Building a design system as a solo designer for Amaze

The Problem

I inherited the project with no existing design system or component library.

The developers had been working on their own for a while, so by the time I jumped in, things were all over the place. There were different components doing the same thing, and lots of UI issues like spacing, font sizes, and using hex codes for colors.

All these inconsistencies kept piling up, creating extra work and leading to a lot of back-and-forth between me, the front-end team, and the client.

Building the Design System

In the brief time that I worked on this project I managed to set up a component library (Amaze DS v1.0) but new components kept popping up from nowhere, buried deep in the app.

It felt like the myth of Sisyphus—everyone was working hard, but the results just weren’t adding up.

A New Design System on a Budget

We needed a design system that would set principles, define a visual language, and organize the component library so we could keep track of everything

Since we were on a budget, I looked into open source libraries:

• ShadCN for the component library
• Radix-UI's color palette generator for creating a custom palette
• Carbon Design System for general design guidelines
• Lucide for icons

This approach helped bring some structure to the chaos.

Challenges

Building the design system was a tough task, but I had great support from both the client and the team.

However, there were some challenges:

• I never built a design system from scratch before - only contributed to them or built component libraries
• as the sole designer, I had to juggle multiple design tasks during this time
• the app had two separate interfaces: a customer-facing "Wallet" and a business-facing "Admin"—they needed to feel cohesive while maintaining key differences.

To tackle this, I paused new feature design for this client and focused on research and building the component library.

Tokens

First, I started building the tokens:

• Colors
• Typography
• Spacing & Radius
• Shadows
• Icons

This approach laid the groundwork for the design system, but it definitely took time and patience.

Assets & Components

I then started building our library by redesigning and adding components from the app, using ShadCN's library as a foundation.

To keep everything organized, I listed them in a table with a status label—like Healthy, Known Issues, or Deprecated, In Progress etc — so we always knew what needed attention.

Documentation

I set up the documentation on Confluence since we were already using Atlassian. At the time, this was enough to help us move in the right direction.

I defined a list of design principles, a visual language and general guidelines for the team to follow. This should help reduce back-and-forth and make collaboration more efficient.

Results

The design system is already improving workflow by reducing inconsistencies and streamlining collaboration.

With a component-first approach, the team can cut down on back-and-forth, avoid redundant redesigns, and simplify feature development.

Next Steps

• Align with the dev team on priorities and handover.
• Replace hardcoded HEX codes with design tokens for easier updates and dark mode support.
• Integrate the new components gradually as features evolve.

In conclusion, this approach makes the design process more efficient and scalable for the long run.

Since we likely won't pause feature development, my plan was to implement the system gradually. Over the next few months, we’d cover everything without interrupting ongoing work.