I haven't opened a wireframing tool in months. Not Figma, not Balsamiq, not even a napkin sketch. Every piece of UX design I've done this year has happened in a terminal window, through conversation.
That sounds like it shouldn't work. Design is visual. You need to see layouts, feel spacing, understand flow. You can't describe a good user interface into existence through text alone. Except - and I'm as surprised as anyone about this - you kind of can.
The Feedback Loop
The workflow looks like this: I describe what I want. Claude builds it. I open the browser, look at it, and describe what's wrong. Claude fixes it. I look again. Repeat until it's right.
That sounds tedious. In practice, it's faster than traditional design-then-build because you skip the entire "translate the wireframe into code" phase. There's no handoff between designer and developer because they're the same person, and the design and implementation happen simultaneously.
The tight loop - build, test in browser, describe what's wrong, AI fixes, repeat - compresses what would normally be weeks of design-review-implement-review into hours. Not because each individual step is faster, but because there are fewer steps. No wireframes to approve. No design specs to write. No "the developer interpreted the mockup differently than the designer intended" problems. Just a continuous conversation about what the product should feel like.
TestPlan: "Come On Claude, Get Clever"
TestPlan's UX went through this process extensively. The sidebar navigation alone was redesigned multiple times through conversation. I'd look at the menu structure and say something like "does it follow a nice flow? A tester would start by looking at their test cases, then run a test session, then check the results. The menu should follow that journey."
That's not a wireframe. It's not a user story. It's a product owner thinking out loud about user behaviour, and the AI translating that into structural changes in real time.
There was a moment during the TestPlan development that I think captures this approach perfectly. We were naming sections of the application, and I wasn't happy with the options. They were functional but boring - the kind of labels that accurately describe what something does but don't make anyone excited to click on them. I said something along the lines of "come on Claude, get clever" - pushing for names that were a bit more thoughtful, a bit more human.
And we got there. Through conversation. Not through a naming workshop or a branding exercise or a stakeholder review meeting. Just through iterative dialogue about what felt right.
Inventing the Inbox
The best example of conversational UX design is probably the TestPlan Inbox concept. This didn't come from a requirements document or a competitor analysis. It came from me thinking about the tester's experience.
Testers don't want to hunt for work. They want to open the tool and immediately know what needs their attention. New test runs assigned to them. Failed tests that need re-running. Test cases that have been updated since they last ran them. All in one place, prioritised, actionable.
I described this to Claude: "I want something like an inbox for testers. When they log in, they see everything that needs their attention, and they can work through it." From that single description, we built the entire feature - the data model, the aggregation logic, the UI, the notification triggers. The Inbox became one of TestPlan's most distinctive features, and it started as a sentence in a conversation.
The product vision was entirely human. The execution was entirely AI. The design happened in the space between.
Task Board: Onboarding and Analytics
Task Board went through a similar process. The onboarding tour is a good example. I wanted something "friendly, a few steps where it shows off key areas" - that was literally the brief. Not a twelve-page onboarding specification. Not a flowchart of user states. A sentence describing the feeling I wanted.
From that, we built a guided tour that walks new users through the kanban board, shows them how to create tasks, explains the workflow columns, and points out key features. It took multiple iterations to get the tone right - the first version was too formal, the second was too long, the third hit the right balance of friendly and informative.
The kanban analytics feature followed the same pattern. I asked: "Can we analyse how tasks move through columns over time?" That question contains an entire product feature. How do you track column transitions? What metrics matter? How do you visualise cycle time? What time periods should be available?
All of those sub-questions got answered through conversation. I'd describe what I wanted to understand as a project manager - where are tasks getting stuck, how long do they spend in each phase, are there bottlenecks - and Claude would translate that into data structures, aggregation queries, and visualisations. When the charts didn't communicate the right information, I'd say so, and we'd iterate.
Why This Works (and When It Doesn't)
Conversational UX design works because it removes translation layers. In a traditional workflow, the product vision lives in someone's head, gets translated into wireframes, gets translated into a specification, gets translated into code. Each translation introduces drift. By the time the code is written, it might bear only a passing resemblance to the original vision.
When the product owner is having a direct conversation with the implementation tool, the translation is compressed to a single step: thought to code. The drift is minimal because the feedback is immediate. You see the result, you react, you adjust. There's no telephone game.
But it requires something that traditional workflows don't: the person in the conversation needs to have a strong product vision. A wireframe can be evaluated by anyone - does this layout look right? A conversational design session requires someone who knows what "right" looks like before they see it. Someone who can look at a screen and say "this flow doesn't feel natural" and articulate why.
If you don't have that product sense, conversational UX design becomes the AI building whatever it thinks is best, which tends toward generic, safe, unremarkable interfaces. The AI is excellent at executing a vision. It's less good at inventing one.
The Speed and Its Dangers
The pace of conversational design is genuinely remarkable. Features that would take weeks of design-and-build compress into hours. But that speed has a danger: you can build so fast that you don't think enough.
Traditional design processes have built-in thinking time. You sketch a wireframe, step away, come back the next day with fresh eyes. In conversational design, the momentum is relentless. You describe something, it appears, you move to the next thing. It's easy to accumulate features without pausing to ask whether they're the right features.
I've caught myself doing this. Building a feature because I could describe it, not because users needed it. The speed of execution can outrun the quality of the product thinking if you're not disciplined about it.
The antidote is deliberate pauses. Step away from the terminal. Look at what you've built with fresh eyes. Ask yourself: would I use this? Would the target user understand this without explanation? Is this adding value or just adding complexity?
What This Replaces (and What It Doesn't)
I want to be clear about what conversational UX design replaces and what it doesn't.
It replaces wireframing for solo developers and small teams building products where the designer and developer are the same person. It replaces lengthy spec documents for features where the requirements can be explored through iteration. It replaces the design-review-implement cycle with a continuous design-and-implement flow.
It does not replace user research. Talking to an AI about what users want is not the same as talking to users. It does not replace accessibility auditing - you still need to test with actual assistive technologies and real users. And it does not replace the need for visual design skills - someone still needs to know that 16px is better than 12px for body text, that contrast ratios matter, that white space is a feature not a waste.
What it does is make the developer-as-product-owner model viable in a way it wasn't before. If you know what you want to build and you can articulate it clearly, the gap between vision and implementation has never been smaller. The conversation is the design process. The browser is the prototype. And the finished product is the deliverable.
No wireframes required.
