Design
Honestly, my early beta looked like a DJ console. Knobs everywhere. Toggles for every route, every model variation, every debug parameter. It made sense at that stage because I needed to test hundreds of permutations.
But when I started using it every day, even I felt interrupted by all those controls.
The Real Goal
Everything I was doing—all those model routes, delay settings, polish options—had one purpose: to give you the version you like best. You shouldn't have to tune anything. You shouldn't even know those permutations exist.
When you see the output and think, "Yes, that's exactly what I meant"—that's the goal. That's the only goal.
Once I realized that, my design principle became simple: If I can hide it, hide it. If I can encapsulate it, don't interrupt the person using it.
The Builder and User Gap
I kept running into a cognitive gap between builder mode and user mode:
Builder instinct: Hand over a full remote control. Every option, every setting. Maximum flexibility.
User reality: The better experience is when what matters simply appears in your feed. No channel switching, no hunting.
This made me rethink a lot. The version you see now? I've cut so much. Features I was proud of at one point—gone.
The Test That Matters
I started asking myself two questions, but not right away. I'd wait a few days. Let the excitement fade. Then:
- Does it make sense?
- Would I actually use it myself?
When the answers changed—and they often did—I cut without hesitation.
Here's the thing: when you're deep in building, everything feels reasonable. But building and using are different perspectives, and switching hats is hard. You can't debug implementation one moment and immediately become a neutral user the next.
So I gave myself buffer time. That's partly why our development cycle was longer than expected. The prototype existed early. Friends were testing it. But we kept polishing, kept asking: Is this actually useful? Would I use this myself?
Eating Your Own Cooking
During development, I used Reso as scaffolding for my own work. And if something felt awkward to me—even as the person who built it—that was a red flag.
Why would I give someone else something I don't want to use myself? It's like giving advice you don't believe in. If someone asks, "Do you actually believe this?" and you say no—everything after that is just noise.
When you finish building something, you have to ask: Do I believe in it?
If you do, you'll communicate it with conviction. If deep down something feels off—you know. You just know.
UI as Expression
This struggle—between what's technically possible and what's actually human—showed up constantly when we built features like Skills and Tones. We kept asking: Are we just impressing ourselves, or does someone actually need this?
But here's the beautiful part: UI is a form of expression. I'm grateful for great art in the world, and I think UI is a window for developers to express what they believe beauty looks like.
There's no "correct" UI. Only what fits. What feels right. What gives people comfort.
And that standard will keep evolving. I'm looking forward to more inspiration, more feedback, more iteration. Because the UI you never think about? That's the one that took the most thought.