We ran our design process on itself, and it broke in useful ways

I'd built this whole AI design workflow, nine steps, gates between them, the works. And I'd tested it the way you test something you're proud of, which is to say gently, on friendly little examples that were never going to embarrass it.

Then I did the thing I'd been avoiding. I picked a real feature, a settings redesign we actually needed, and ran the whole workflow on it start to finish. Every step, in order, no skipping ahead to the fun part.

I was still there, obviously. The gates are the point of the thing, so I answered every one of them and made real calls throughout. What I didn't do was step in when the process wobbled. If a step produced something odd, I let it produce something odd and wrote down what happened instead of quietly fixing it and moving on. That restraint is the entire experiment.

It worked. It also broke in about a dozen places. The breaking is the part worth writing about.

What only shows up when it's real

Every failure was something a friendly test would never have surfaced.

The very first step skipped a question it should always ask. On this run there was no PRD to work from, and the question, which was about where the feature's Figma file lives, had been hiding inside the PRD path. No PRD, no question. Nobody would have caught that on an example that happened to have a PRD, and the setup checklist now runs independently of whether a PRD exists.

The push into Figma captured one screen per flow and dropped every other state. The empty ones, the error ones, the loading ones, the exact states a real feature has and a demo doesn't. The intent was there in the instructions. Nothing enforced it, and the delegated worker had been told, in so many words, to capture the default view. There's a coverage check now that counts the frames it expects before it starts and refuses if the plan covers fewer.

A push succeeded and the AI thought it had failed. It uploaded some reference images to Figma, they went in perfectly, and then its own verification screenshot came back as a grey broken-image placeholder, because of the image format we'd used. So it reported a failure that hadn't happened. That one rearranged how I think about verification. A false negative in your checking layer is worse than no checking, because it sends you debugging a thing that works.

A safety layer blocked the workflow, correctly, and nobody had told the workflow. The step that hands capture off to a spawned helper got stopped by a classifier, since spawning a headless worker with shell access is exactly the kind of thing that should give a system pause. Fine. But the workflow had no idea that was a possibility, so it read the block as a capability gap and started looking for a workaround.

And one small, stupid, real one. Wireframe rounds were being written as a folder per iteration, each with its own files inside. Browsing a round meant opening five folders. I complained about it within about ninety seconds of seeing it, which is roughly ninety seconds longer than it would have taken me to notice on a demo with one wireframe in it.

None of these were dramatic. That's the point. They were small, specific, and completely invisible until a real feature dragged them into the light.

The thing that went right was also only visible here

Worth saying, because dogfooding writeups turn into misery lists.

The prototypes came out looking exactly like production, and the reason was a technique the run invented under pressure. Rather than rebuilding the app shell, it lifted the host markup straight out of the real captured page, swapped only the content region, and then pointed the stylesheet at our actual production CSS instead of the copy saved alongside the snapshot. So every real utility class rendered exactly as it does in the product.

I liked it enough that it stopped being a technique and became a rule. Every prototype does it now. That came out of a real run too. It's not a thing you think of while designing a workflow in the abstract.

The scoreboard

By the end I had a list. Twelve findings about the workflow itself, and ten new rules about my own taste that the feedback loop caught along the way. Every one of them was a thing I would have sworn was already handled, right up until it wasn't.

I fixed them in batches over the next few days. The workflow is meaningfully better now, and none of the improvements came from me sitting around imagining how it might fail. They came from watching it fail at something I actually cared about getting right.

You cannot design-review your way to this. A review looks at the thing and asks if it seems right. Dogfooding uses the thing and finds out. The gap between "seems right" and "survived contact with a real task" is where all the interesting bugs live, and the only way across it is to trust your own tool with real work and then write down everything that made you wince.

It's uncomfortable, because you're basically running an experiment designed to make your favourite thing look bad. Do it anyway. The wince list is the most useful document you'll produce all quarter.

---

Part of a series on building an AI collaborator for our design team at Xflow. Each post stands on its own.