What the poll made obvious

I ran a quick poll this week to see what you want more of.

I had a guess. I was wrong.

Here’s what came back.

AI workflows in real product work: 60%
Real product breakdowns: 40%
Everything else: basically noise

Small sample, but clear enough.

Why this matters

Most of the talk online about AI in design is still surface level. Tools. Prompts. Outputs. A lot of it is just noise, and honestly a bit of bullshit.

What people actually want is how this shows up in real work. Not theory. What changes day to day. Where it saves time. Where it breaks. Where it makes you look smart. And where it can make you look dumb if you’re not careful.

Core narrative

The real shift isn’t that AI can generate things. It’s that it speeds up feedback.

Earlier this week I talked about skipping wireframes on a feature because they weren’t proving anything about the logic. That keeps happening.

The tools don’t replace thinking. They just remove the delay before your thinking gets tested.

So the skill moves earlier. Less time making things. More time deciding what’s worth making.

What this actually looks like in my workflow

Here’s how I’m using it right now.

I use Claude as my main tool. It’s connected to GitHub, Atlassian, Figma, and Slack. So it has real context. It knows the product, the constraints, and how things actually work.

When I start a feature, I don’t jump into design. I load context first. PRD, notes, screenshots, anything that shows how the product behaves. I feed it in step by step and tell it to wait.

Then I ask for ideas.

I’ll generate 4–5 versions in separate threads. Not to find the best UI, but to see what breaks. This is where bad ideas die. Usually 2 of them fall apart right away, which is kind of the point.

Then I take the best 1–2 and stress test them. I ask it to critique the flow or point out risks. Not because it’s always right, but because it helps me catch things faster.

I also use Cursor for quick experiments.

This week, engineering needed a real solution for an accessibility issue before the end of the sprint. It was about focus order for an action bar that appears when you select rows in a table using checkboxes.

I built a simple HTML demo and used Cursor to move fast. We fixed focus so it returns to the right place after updates. We moved the banner in the DOM so it makes sense logically, but still stays fixed at the top visually. And we cleaned up keyboard behavior so tabbing feels normal.

The rules kept changing as we tested edge cases. Cursor made it easy to adjust without getting stuck.

Instead of talking about it, we had something real for engineering to react to.

After that, I move to Figma and clean it up.

What used to take hours now takes about 20–30 minutes to explore and kill bad ideas early.

Where this breaks (and where people get burned)

AI sounds confident. Even when it’s wrong. And it will absolutely fuck things up if you trust it blindly.

It will make up copy. It will invent edge cases. It will suggest things that would never work in your real product.

Anything beyond quick UI needs to be checked. Every time.

If you don’t, you’ll present something that looks good but is wrong. That’s how you lose trust and look sloppy.

What I’m going to do with this

Based on the poll, I’m going to focus on two things:

1. How I actually use AI in product work (not demos)
2. Real feature breakdowns (what worked and what didn’t)

Less theory. More real work.

If there’s something else you want me to cover, just reply to this email. Seriously. I read every message.

Practical application

If you’re trying this out, don’t change everything.

Pick one slow step and replace it. Wireframes. Exploration. Copy. Anything that delays real feedback.

Then watch what happens.

Prompt to think this through

Where are you spending time that isn’t actually proving anything?

I’m a product designer working on a feature inside an
existing system with real constraints (design system, data models, user expectations).
I’ve provided context including product behavior, requirements, and research.
Do not generate a solution yet.
First, confirm you understand:
• the goal of the feature  
• the constraints of the system  
• the expected user behavior  
Then, generate 4–5 different solution directions.
Important:
These are not final designs. These are exploration paths.
For each direction:
• describe how inputs flow through the system  
• explain how outputs are affected  
• call out where the logic might break or fail  
• identify any edge cases or missing states  
After generating directions, evaluate:
• which concepts are worth exploring further  
• which should be killed early  
• where the system behavior might confuse users  
Do not optimize for polish.
Optimize for:
• exposing bad ideas quickly  
• revealing logic gaps  
• identifying points of failure  
Assume:
• this will be used in a real production system  
• engineering constraints are non-trivial  
• anything that “looks right” but doesn’t hold up logically is wrong  
I’m not looking for a perfect solution.
I’m looking for the fastest way to figure out  
what doesn’t work.
        

Close

Appreciate everyone who voted and replied.

If you want me to break something down, just reply.

Also, if you want the full breakdown of how I’m thinking about this, we went deep on it in this week’s podcast episode. No hype, no "just vibe code" nonsense. Just how this actually shows up in real product work.

​

Full episode with Co-host: Nick Groeneveld

​
Talk soon,

Tyler White Helping designers prove the ROI of their decisions