Diving Into Colors: How I Chose My MVP Strategy

This week, Designinator hit a familiar point: too many ideas, no clear next step. It’s in no way finished, but I was overwhelmed by the number of features I had dancing around my head. It made it hard to actually, you know, start.

So I went back to a tool I’ve used to solve this problem for other startups: Miro. I knew what I was building toward: a robust, usable design system in hours instead of weeks. I needed a strategy to get there.

I landed on two different approaches.

Breadth First

Extract tokens for every aspect of the design system from the start, then get them into usable artifacts (Tailwind class names, Figma tokens, etc.), add a GUI for managing them, add features to update the codebase automatically, and finally offer up suggestions for improvement. This path would require a lot of work in the beginning, figuring out possible token schemas for nearly every aspect of the UI. But when it was done, it would work for the whole design system and not just one aspect.

Depth First

Extract and tokenize colors only, turn them into usable artifacts, add a GUI for management, allow users to update the codebase automatically, and finally provide suggestions. Then build out support for the rest of the tokens.

User Research

I was inclined to go depth first, because I knew it could get me to something usable faster. But depth first can be risky if the solution you’re going deep on doesn’t solve a real problem. For the startups I’ve worked with, my inclination when evaluating a depth-first approach like this is to go to the users: would the depth-first MVP be something they would be excited about using? Would it solve a real problem for them?

I started to despair about not having users to interview when I remembered: I’m the user. I’m building this because it’s something I’ve needed.

Color Spread

And the colors alone would’ve been exciting. For me, consistent colors were the aspect of a design system I needed most. You start with five colors, and before you know it, they’re everywhere: used inconsistently, layered incorrectly, and added by both human and AI developers alike. Colors are a big deal.

Since I’m building this open source, starting depth first will make it easier for future contributions. Once the pipeline works for colors, it becomes much easier for someone to add support for border radius or spacing without rebuilding the GUI from scratch.

Choosing depth first means Designinator will be useful sooner, even if the scope is limited. I’ll start with colors. Then we expand.