AI can generate a polished product interface in minutes. That makes it very easy to assume the prompt deserves most of the credit.
I wanted to test that assumption with my team, so I gave three designers the same brief: build a personal AI assistant, choose the one or two things that matter most in your role, and go deep instead of trying to cover everything. They each had 30 minutes, and we judged the results on usefulness, taste, and speed.
Every person started from the same constraint. By the end, we had three products that solved different problems, behaved differently, and felt like they belonged to different people.
The prompt created a starting line. The designers shaped everything that came after it.
Table of contents
- What is AI product design?
- The experiment: one brief, three assistants
- What changed the outcome
- How to get better results from AI design tools
- What this means for product teams
What is AI product design?
AI product design is the use of AI throughout the product design process to turn context, ideas, and constraints into flows, interfaces, prototypes, and production-ready decisions. The designer still chooses the problem, decides what deserves attention, evaluates the output, and gives the system enough context to improve it.
This distinction matters because a generated interface can look finished long before the product thinking is finished. AI can create a sidebar, dashboard, calendar, chat panel, and polished cards from one prompt. It cannot know which customer update is worth surfacing, whether a meeting needs a context drawer, or why a bowl of pasta would make follow-ups more motivating unless a person brings those decisions into the process.
The experiment: one brief, three assistants
The three designers worked in Codex and used voice prompting to move quickly. They could iterate, add screenshots, and bring in references from real products. Beyond that, each person had to decide what “personal assistant” should mean for their own work.
A Slack follow-up assistant with a pasta progress tracker
The first designer spends a large part of her day in Slack, following up with design associates and customers. She built the assistant around that reality. The product let her see follow-ups in one place and complete them without opening multiple threads or channels.
She also asked for a playful pasta progress indicator. As tasks were completed, the bowl filled with pasta, and the user could choose shapes and sauces. It sounds like a small detail, but it made the product feel personal and gave routine follow-ups a visible success state.
The first generation had a dark interface and colors she did not love. She gathered references from real products with cleaner cards, calmer colors, stronger hierarchy, and more visible metrics, then asked Codex to apply those qualities. The final direction became easier to scan while preserving the pasta interaction that made it hers.
A design lead dashboard built around context
The second designer focused on the context he needs to support customers and associates. His assistant combined an agenda, customer information, associate tasks, blockers, meeting preparation, and an AI chat.
His first pass contained the right sections, but the visual hierarchy, typography, and interactions fell short of what he had in mind. He added references from products such as Notion, Linear, Attio, and Google Calendar, then iterated on very specific behaviors: an expandable sidebar, hover summaries, a weekly calendar, and a side panel that changed based on the selected meeting or task.
That process gradually turned a broad dashboard into a context engine. A calendar event could reveal the purpose of a meeting, a customer card could open a detailed brief, and the interface gave associates more of the information they would normally need to ask a lead to explain.
He completed the product in about 20 minutes, the fastest strong result in the experiment.
A client assistant with a character and post-it notes
The third designer chose two recurring parts of associate work: turning meeting transcripts into design tasks and writing client updates. Her assistant included meetings, clients, async updates, useful links, and prompts ready for the next design iteration.
The first output was functional, but it felt visibly AI-generated. She wanted everything to fit on one screen, then introduced a character connected to a personal inside joke, handwritten type, brighter colors, post-it graphics, and a two-column layout. She also made meetings interactive, so selecting one could generate a transcript, task list, and draft update.
After several rounds of feedback, the product felt much closer to something she would actually keep open during the day. The character changed expressions when clicked. Tasks could be added and removed. Client links were editable. The visual language carried her personality while the workflow handled repetitive work.
That combination of utility and personal taste made it the overall winner.
What changed the outcome
Looking across the three assistants, the biggest differences came from four design decisions.
1. Each designer framed the problem through their own role
“Build a personal AI assistant” leaves a lot unresolved. One designer saw a Slack follow-up problem. Another saw missing customer and meeting context. The third saw a way to turn transcripts into tasks and client communication.
This is product judgment. Before a screen exists, someone has to choose which part of the workday deserves a product at all. A broad prompt can generate many features, but usefulness comes from narrowing the scope around a real, repeated behavior.
2. References communicated taste faster than more adjectives
All three designers improved their products by showing Codex examples from real interfaces. “Clean,” “premium,” “minimal,” or “less AI-generated” can point in a direction, but those words leave enormous room for interpretation.
A screenshot gives the model visible evidence of hierarchy, spacing, density, typography, border treatment, interaction patterns, and color. The designers still had to explain what they liked in each reference. That combination worked better than asking for a vague aesthetic and hoping the output matched the picture in their heads.
3. Interaction details turned dashboards into tools
The first outputs often had the right ingredients. They looked like dashboards, with cards, navigation, a calendar, and a chat area. The products became useful when the designers pushed deeper into behavior.
Follow-ups could be completed from Slack. Hovering over a calendar event revealed meeting context. Selecting a client changed the information in a side panel. A transcript became a task list and a ready-to-send update. These decisions removed small pieces of daily friction and connected the interface to actual work.
4. Personalization created reasons to return
The pasta bowl, the animated character, the post-it notes, the calm monochrome calendar, and the specific information hierarchy were never requested in the shared brief. They came from the designers’ preferences and understanding of how they wanted to work.
Some of these choices improved comprehension. Others made the experience more enjoyable. Together, they moved the products away from the familiar average of AI-generated UI. This is where taste becomes practical: it guides what to keep, what to remove, what feels generic, and which tiny detail makes a tool feel worth returning to.
How to get better results from AI design tools
The experiment also gave us a repeatable AI design workflow. If you are building a prototype with Codex, Claude Code, or another AI coding tool, these five steps will improve the odds that the result becomes genuinely useful.
1. Start with one recurring job
Choose a task that happens often and carries enough friction to be worth improving. “Help me manage my work” is too broad. “Turn a meeting transcript into a task list and client update” gives the product a clear input, transformation, and outcome.
Ask yourself: What do I repeat every day or every week? Where do I lose context? Which task makes me jump between several tools?
2. Define the important information and actions
List what the user must understand and what they should be able to do. For a meeting assistant, that might include the meeting time, customer, goal, open questions, relevant files, and next action. For a follow-up assistant, it might include owner, status, urgency, and a way to respond without changing screens.
This gives the model more than a feature list. It explains the structure of the work.
3. Generate the first version quickly
Treat the first pass as material to react to. A working prototype makes missing context visible in a way that a long speculative prompt rarely does. You can see when the hierarchy is weak, when the calendar takes up too much space, or when a workflow stops after displaying information instead of helping the user act.
The first version has value because it gives the designer something concrete to judge.
4. Add real visual and product references
Capture examples of the qualities you want, then annotate them in plain language. Explain that you like the way one product handles density, how another reveals a side panel, or how a third uses typography to separate primary and secondary information.
Avoid asking the model to copy an entire interface. Pull out the underlying pattern and connect it to your own workflow.
5. Iterate on behavior as carefully as appearance
Once the direction feels right, test what happens when someone clicks, hovers, completes a task, changes a client, or opens a meeting. Check empty states, success states, and the transitions between pieces of context.
This is often the point where an AI-generated UI becomes a credible product prototype. The designer has moved beyond arranging the right pieces and started shaping how the product responds to someone using it.
What this means for product teams
AI has compressed the time between an idea and an interactive prototype. We saw that happen three times in this experiment, with every designer reaching a working product in 30 minutes or less.
Speed changes the economics of exploration. A product team can test several directions in the time it once took to prepare one polished mockup. The experiment also shows why faster generation increases the importance of judgment. When screens are cheap to produce, the valuable work moves toward choosing the right problem, supplying context, recognizing generic output, and refining the interactions that make the product useful.
This is already changing how we work at TDP. We can move from Figma concepts into production-ready code much earlier, but the strongest results still come from designers who understand the customer workflow and can guide the system with specific references, constraints, and feedback. I shared more of that process in our guide to building an AI design workflow.
The shared prompt in this experiment never determined the Slack integration, the calendar context panel, the transcript-to-task flow, the pasta bowl, or the character. Those came from three people noticing different things and caring about different details.
AI made each product possible in under 30 minutes. The designers made each one worth judging.
If you want to try the same kinds of workflows with your own team, you can access the AI tools and skills our designers use.
You can also join the TDP Community for monthly sessions, recordings, feedback, and practical design-to-code resources. If you are exploring this at a company level, learn more about our AI product workflow workshops.
Related reading
- Claude Code vs Codex: Same prompt, same repo, very different results
- AI design workflow: The toolkit I use to go from inspo to code in minutes
- Mobbin MCP: Pull design inspiration in Claude Code without a single screenshot
- Agent skills: Stop re-teaching AI your design system
