I Stopped Prototyping and Started Building
How I rebuilt my design process from scratch — and burned $1,000 in tokens to learn how to use AI as a designer and not a slop generator
There's a specific kind of exhaustion that doesn't show up in a sprint retro. It's not the exhaustion of designing. It's the exhaustion of explaining what you designed — over and over, to different people, in different formats, on different days - until the explaining becomes the job. That was my Q1
As a designer sitting across three pods at Whatfix, each pulling in a completely different direction:
Guidance Pod — our mature Digital Adoption Platform (DAP), self-help flows
Seek Pod — our conversational AI product, still finding its shape
Platform Pod — platformizing existing mobile and web products from the ground up
Three problem spaces. Three sets of stakeholders. One brain.
Every design decision needed to be documented, reviewed, and re-explained — to PMs who missed the sync, to engineers who needed a recorded walkthrough, to leadership who wanted a five-minute version of a five-week thought process. I was recording Loom-style videos, scripting them, editing them, cutting them down for different audiences, re-recording when Figma glitched mid-capture. I was spending more hours aligning people on the idea than I was spending close to the customer, validating whether the idea even worked. That imbalance is what broke me into building something new.
What If the my ideas were self explainable
The idea was simple to think and hard to build: - a tool where anyone — PM, designer, or engineer — could just hit record on their screen, talk through their thinking out loud, and have AI automatically turn that raw capture into a clean, chaptered, zoomed-in walkthrough video. No scripting. No editing software. No re-recording because you fumbled a sentence.
I decided to build it as a Chrome extension, and I decided to build it almost entirely inside Claude Code. What followed was a month-long, deeply iterative process that taught me more about how to think with AI than any tutorial ever could. Here's how it actually went - failures included.
Chapter 1: The Prompting Trap
My first instinct was the one every designer has when they meet a capable AI for the first time: I threw a rough screen and a prompt at Claude and hoped it would read my mind. It didn't. It gave me an element heavy interface with no visual hierarchy - busy, generic, technically functional, aesthetically nowhere.
So I did what a lot of us do next: I asked ChatGPT to write me a "better prompt" for Claude code. The output improved slightly. It was more organized AI slop, but it was still AI slop; technically coherent, emotionally empty, with no real point of view. I kept iterating this way for a while, tweaking prompts, hoping the next one would be the magic incantation. Instead, the outputs got less reliable. Eventually Claude started hallucinating features I'd never asked for.
That's when I realized the problem wasn't the prompt. It was the format.
Chapter 2: From Prompts to a Living Document
Instead of writing another prompt, I opened a Google Doc. No instructions to build anything ; just reasoning. What problem I was solving. What I wanted to capture. What the experience should feel like. What elements I imagined needing. It read more like a product note to myself than a spec for an AI.
I fed that document to Claude and asked it to turn it into a markdown file. Something shifted. Claude didn't try to build anything. It reflected my thinking back at me, structured, cleaner than I'd written it - and it turned into a markdown file that became the source of truth. I realized Calude didnt need better prompts. It needed better context ; context that evolved with my thinking.
So I created a master .md file, a running brain dump and explicitly told Claude: review this, don't build anything yet. Treat it as a diverging document, not a build spec. The response surprised me. Claude reflected back a strong understanding of the problem and asked clarifying questions , that pushed my thinking into directions I hadn't considered. For the first time, the conversation was about the problem, not the output. I wasn't managing an AI. I was thinking out loud with a very well-read collaborator.
Chapter 3: Forming a plan
I built a rough Figma file with annotated ideas just enough to point Claude toward what I had in my head and combined it with the master markdown file. Then I asked Claude to break the whole thing into phases, planned so I could review after each one.
Claude split the build into seven phases, each with a clear scope: what it would touch, what would carry over, what dependencies it needed. Upfront, it even asked whether any backend API keys were required, I shared my personal ElevenLabs API key, kept local, never exposed.
Phase one: the extension shell, triggerable from Chrome built and ready to be added in the chrome extension
Chapter 4: Building taste
Once the base phases were ready and was functional, I needed to build taste — a sense of what "thought through" looked like in this specific space. I installed a set of design-craft skills for Claude (I've come to think of them as "impeccable" and "taste" skills) and connected the Mobbin MCP, which let Claude pull in real reference screens from comparable products.
Claude synthesised references into a useful starting point, not to copy, but to calibrate. From there, I used the taste skill layer to brainstorm past pure function: not just what the tool does, but its form , the intermediary actions, the micro interactions, the experience.
The result was a detailed markdown file with forms, functions, modals, copy ready to be executed. which included ideas from me , similar products knowhow along with