Short steps, checked often

The rhythm was a day per iteration. That’s only possible if nobody’s guessing.

I taught Alfie, our product cofounder, to write user stories — which turned out to help me as much as him, because reading them was how I learned the product from the user’s side. From there: a rough sketch to make sure we pictured the same thing, then wireframes, then design. Each stage a day, four or five hours.

Sounds like overhead. It’s the opposite — the sketch exists so you don’t spend a day designing the wrong idea.

The Podcast-to-Blog screen from sketch to final

Making the case, not just the screens

Neither cofounder had worked with a designer before, so part of the job was building a shared language for it — why a design system pays for itself, why structure matters before pixels.

For bigger decisions I’d research first and bring a deck. The chat feature was the clearest example. Everyone was putting chat first that year, and I argued against it for this product: mixing dialogue, tool settings and results into one thread overloads people, power users lose speed, multitasking gets hard. My analogy at the time was that it’s like cramming Photoshop into a chat window.

Then I compared four approaches and recommended a hybrid, with a scoped MVP so we could start small. The deck wasn’t there to win an argument — it was so we could disagree about the same thing.

From the chat deck: four approaches compared, and where each one fits.

Untangling what belonged to what

The product treated the tool, the session and the generated assets as one blurry thing, which is exactly how it worked underneath.

They're not one thing, though. A tool can be rerun, and rerunning it makes a new session. Assets belong to the session, not the tool. Once I split them apart and gave each its own place on screen, the layout stopped needing explanation — proximity did the work.

That's the pattern I keep running into with early products, and I ended up writing about it separately: interfaces built on the developer's mental model instead of the user's.

Splitting tool, session and assets — and giving each generation step its own status.

New mechanics, familiar shapes

The product ran on MUI. Where the library fit, I used it — tabs, fields, buttons, avatars. Where it almost fit, I extended it and kept its naming and props, so ChipCustom behaved like a Chip and the developer didn't have to learn a second system.

Where it didn't fit at all, I built from scratch: nodes, input and output boxes, node headers, the field types for the data extractor — plain text, paragraph, list, group of fields, list of groups, each collapsible. But even then the variants followed the same logic, so new pieces landed in the codebase as extensions rather than exceptions.

My favourite small thing: the node component has a Tested state. The founder was firm that nothing should be a black box, and this is where that turned from a principle into a property. During generation each step reports for itself — transcribing, extracting quotes, drafting — with a stop button, so you always know what's running and what's already done.

Nodes on the canvas, each carrying its own state.