Written with the editorial assistance of Claude (Anthropic).
In Part 2, I shared the stack that made the Playground possible. Eight tools, four days, zero lines of code.
This post is about what came next.
A quick distinction before we go further
Two things in this series share a stage. They aren’t the same thing.
- The Playground is the testing environment I built in four days. It’s the venue.
- The prototypes are the eight new app designs we tested inside it. They’re the show.
Building the Playground in four days was incredible. But not all AI work is that simple. Designing the prototypes that lived inside it took a month. Both are true.
This post is about the slower story, the one that doesn’t make the headline.
I wasn’t designing alone
The dream scenario for a project like this includes dedicated UX research, interface strategy, accessibility planning, and visual design support throughout the product lifecycle. That wasn’t the budget I had.
What I did have was a talented designer: Lila Hinds.
Lila joined the project as a paid contractor, designer, and creative partner.
Her role extended far beyond making screens look good. She helped shape the visual language of the platform, challenged assumptions in the user journeys, and brought the kind of design thinking that keeps a product focused on the people using it.
In a project built around testing ideas quickly, that perspective became essential.
How the work actually divided
Lila took the landing pages and the visual foundations. The pieces that established the language of the platform, the polish a user sees first, and the visual ground everything else stood on.
That part was hers. Everything that followed depended on it.
The work that came next wasn’t a single repeatable sequence. It was a loop, and I want to walk through it because the shorthand “a loop” undersells what was actually happening.
It started with scope. As the PM, I had to define what we were building, who it was for, and what the constraints were. The 95% adoption rate we’d already earned wasn’t going anywhere, and every prototype had to hold up against that bar. That work happened before any design path began.
From there, the design work took one of three paths.
Path one. I’d start with a lo-fi sketch, workflow, or concept based on the requirements and user feedback. Lila would transform those rough ideas into high-fidelity designs. Sometimes she refined the original direction. Sometimes she pushed back. Sometimes she rebuilt a section entirely when a stronger solution emerged.
Path two. The requirements were clear enough that I could move directly into AI-assisted prototyping. Claude would generate an initial working experience we could evaluate quickly. Lila and I would then review the output together, identify what was off, and refine it until it matched the standards we were aiming for.
Path three. A concept would evolve through discussion and iteration until it looked very little like where we started. Those were often the strongest outcomes. The final design wasn’t my sketch, Lila’s first draft, or AI’s initial output. It was the result of combining product requirements, user needs, design expertise, and several rounds of refinement.
What stayed constant across all three paths: every design passed through Lila’s eyes before it went into the Playground for testing. She was the final QA on the work, regardless of how it got there. Did the design match the UX intent? Did it lose nuance somewhere in the process? Did it add things that didn’t belong? Her judgment was the gate.
One workflow illustrates the process well.
For a volunteer workflow, my initial sketch included multiple decision points that felt logical on paper. During review, Lila identified places where users could become uncertain about what to do next. Together, we simplified the flow and clarified the journey before AI ever touched it.
Once the direction was set, AI generated a working HTML version in minutes. What would have taken considerably longer to prototype traditionally became something we could test almost immediately. But the speed wasn’t the lesson. The lesson was that the quality of the output depended entirely on the quality of the thinking that happened before the prompt.
AI accelerated execution. It didn’t replace design decisions.
As a PM, that became one of the biggest takeaways from the project. AI can generate screens, layouts, and workflows. It cannot decide which problems are worth solving. It cannot weigh competing user needs, balance organizational goals, or determine whether a design supports the outcomes you’re trying to achieve.
Those decisions remained human decisions throughout. If anything, AI made product judgment more important because it dramatically increased the speed at which ideas could become reality.
What designing under real constraints actually looks like
Necessity breeds innovation, but it also breeds humility.
I know what good product experiences feel like, even when I can’t personally create every element required to achieve them. That distinction mattered throughout this project.
It allowed me to guide ideas toward the right outcomes while relying on specialists where their expertise was stronger than mine. The combination of product direction, design expertise, and AI-assisted implementation proved far more effective than any one of those pieces alone.
What surprised me wasn’t how much AI could help me prototype. It was how much I still needed a designer in the loop to maintain quality.
We could have built without Lila. The prototypes would have existed. Volunteers could have clicked through them. But the quality of the work would have suffered, and our 95% adoption rate isn’t built on prototypes that merely exist. It’s built on work that respects the user enough to be good.
Once we had a design system in place, that quality compounded. Lila could move into in-app animations, the kind of micro-interactions that turn a flat experience into engagement. Those animations aren’t decoration. They’re how a user knows the product is paying attention to them.
AI built the structure. Lila and I built the experience.
Access, not expertise
Here’s the line I keep coming back to.
AI changed my access. It didn’t change my expertise.
Refining the eight prototypes took a month. That’s the part of the story people often miss.
Without AI, producing eight distinct concepts at that level of polish would have taken three to five months and a much larger team. The work itself didn’t disappear. The design reviews, user considerations, documentation in markdown docs, discussions, and refinement were still there.
What changed was the speed between idea and artifact.
Instead of spending days or weeks waiting for concepts to become something tangible, we could evaluate working experiences almost immediately. That allowed us to spend more time discussing whether an idea was good and less time waiting to see it.
The result wasn’t less work. It was more learning in the same amount of time.
Lila made sure the work was something a user would actually want to use. Neither of us was going to shortcut the part that actually mattered.
The story of designing inside the Playground isn’t “AI replaced our designer.” It’s “AI made it possible for one designer and one PM to do the work of a much bigger team, over a month of feedback, refinement, and human judgment.”
That’s a different story.
And it’s the one that’s actually true.
What comes next
Three lessons stayed with me from this stretch of the work.
AI accelerates execution, not judgment. It can generate. It cannot decide.
Design expertise becomes more valuable, not less. The faster you can prototype, the more it matters that you’re prototyping something worth building.
User adoption is the only metric that counts. Everything else is hypothesis until volunteers prove it true.
The Playground was built in four days. The eight experiences inside it took a month. Without AI, that work would have taken three to five months and a team we didn’t have.
AI reduced the distance between an idea and something real enough to evaluate.
The human judgment that filled the time between is why any of it mattered.
AI changed my access. It didn’t change my expertise.
Part 4 is where the hypothesis met the volunteers.