When to AI

Not every design problem is worth an AI prototype. Here’s how I decide.

When a new project finds me, I’m often caught between the desire to go all-out AI and the lure of the quick one-off wireframe. Out of that tension, I found myself trying to articulate when it makes sense to use AI in design and when time and effort are better spent on traditional methods. The short version: AI earns its keep when the work compounds, and traditional methods win when it doesn’t.

How much time do you have?

Time is the one question that overrides all the others, so it’s always the first one I ask. Before investing in setting up the foundation for a prototype, I make sure my time expectations match my stakeholders’. If Product is expecting something the next day, I start with a Figma wireframe and, depending on scheduling, build it out as a prototype when the schedule allows.

Will it compound?

The trickiest call is whether the work is a one-off, because today’s one-off can easily become the launching point for tomorrow’s feature. But building infrastructure for a small throwaway change can eat up your time — and your token budget — and a throwaway design rarely earns back what you spend prototyping it. I stick to traditional wireframing unless I think it could lead to bigger things.

For a new feature or a change to an existing one, I pay the upfront cost and use AI. My usual flow is to discuss requirements with the primary feature owner, typically Product, then create a low- to mid-fidelity wireframe to verify design direction. From there I move into an AI design tool.

My general rule of thumb is to reach for a quick wireframe when the design covers an edge case — say, the error state when a component hasn’t been configured. Edge cases are one-offs by definition; they’ll never compound. On the opposite end, a prototype was definitely the way to go when I worked on a large feature adding enhancement tools to an existing video-analysis product. With all the different combinations of tools and history, I couldn’t imagine trying to cover every scenario in a Figma flow. As a working prototype, it served both to communicate the design to stakeholders and to gather customer feedback.

How many states are there?

As you work through a feature, you might find you need to cover many different states. Covering all of them in Figma can be a hair-pulling endeavor: even with variants and component properties, you spawn variation after variation, tweak one, and then have to remember to update all the others. Moving the design into a tool like Claude Code makes this easier — lay out the design once and let the AI handle the variations. Newer models are good at tracking a change you make in one state and flagging the other states that need the same update.

Is the plumbing in place?

Finally, consider how much of the core product already exists. If the plumbing is in place — shared components, data models, the surrounding screens — then adding a new feature is a light lift and AI pays for itself quickly. If you’d be building that foundation from scratch just to prototype a single screen, the math changes, and the upfront cost is harder to justify.

This is also where the edge-case rule bends: once the foundation exists, even a one-off error state is cheap enough to add to the prototype.

One approach I’ve taken is to use whatever spare time I can eke out to slowly build up the foundation of the prototype — or, when adding a new design, to take the opportunity to build out adjacent screens. It takes a while, but eventually enough of the app exists that adding new features is a lot quicker and easier.

The throughline

Schedule permitting, reach for AI when the work builds on itself — when states multiply, when features stack on each other, when the foundation gets reused. When it’s a throwaway, traditional wireframing is still the faster, cheaper bet.

A footnote on tools

There are plenty of AI design tools to choose from — Figma Make, Claude Design, Google Stitch — but I’ve gotten accustomed to starting with Claude Code. It runs locally, so the prototype lives on my machine and I can always run the app myself, no hosted service required.

This is a ‘timbit’ post — an idea to expand on in the future