Prototype in two hours: AI workflow that I use on every project

The prototype, which used to take two days, is now done in two hours. This is not magic or marketing of AI tools – this is a specific workshop, in which each step is reduced by 3-5 times due to the correct use of generative models, finished components and Figma.

But honestly, I’ve seen a lot of designers who have tried “prototyping through AI” and become frustrated. It turned out slower than hands, the result was garbage, and edits took more time than assembly from scratch. The problem isn’t with the tools — the problem is that people have tried to use AI as a “design” button, rather than as part of a process with an understandable role at every step.

This article is about what really works on projects. Without promises of a “prototype one-prompt” and without advertising specific services. Workflow is described so that it can be assembled from any tools at hand.

---

## Why speed up prototyping at all

### A prototype is not an artifact, but a tool of thought

The main mistake is to treat the prototype as an intermediate design that needs to be “bringed to mind”. A prototype is needed to:

• Test the solution hypothesis before budgeting
• Show stakeholders not a description, but experience
• Find Logic Holes Before Meeting Development
• Let the user click and see how they really behave

The faster the prototype appears, the more iterations fit into the project. Design quality is determined by the number of iterations, not by inspiration or talent.

### What changes AI in this logic

AI doesn't make a prototype for you. AI removes the three most expensive stages in time:

• **Start inertia. ** You don't have to sit in front of an empty artboard. The first draft comes in 10 minutes.
• Texts, names, numbers, descriptions of cards, states are no longer blockers.
• Finding references and solutions. AI works great as an assistant curator if you ask the right questions.

The designer remains in the role of solution architect and result editor. This is important – without editing, the AI prototype slides into an average universal template.

---

## What to do before you open Figma

The most common reason for slow prototypes is to start from the screen. If you don’t have the answers to the basic questions, you’ll redesign every 20 minutes.

### Minimum brief to yourself

Before the start, I answer five questions in writing - it takes 10-15 minutes:

• What task should the user perform in this prototype?
• What would have to happen for me to consider the prototype a success?
• Which 1-2 screens are exactly key, and which are the bandage?
• What level of detail is needed: lo-fi for logic or hi-fi for presentation?
• Who will be watching and what should be clicking in their head?

Without this, AI becomes useless – it generates something about the product, not a solution for a specific task.

### Anti-patterns at launch

• Start by looking for inspiration in Dribbble.** Takes an hour and diverts focus to visual instead of logic.
• Do hi-fi at once. Expensive to rule, psychologically harder to throw away.
• Ask AI to “invent a screen.” Without context, generalized garbage comes out. Context is your job.
• Ignore the existing design system. A prototype that does not fall on the system cannot be transferred to the development - it is redesigned.

### Checklist for prototype readiness

• The user task is formulated with one sentence n
• It is clear what is “prototype success”
• Selected level of detail (lo-fi / mid-fi / hi-fi)
• Have access to a UI kit or design system
• I know who you show and why

If at least one item is empty, do not open Figma. First close the space, then start.

---

## Step 1: Structure Flow through AI Dialogue (20 minutes)

The first thing I do is I don't draw, I say float in a chat with a model. It’s not “make me a script,” it’s a structured dialogue from which the screen map emerges.

### How I build a prompt

Not one message, but a series. First context, then task, then constraints, then request. AI works multiples better when it sees a chain rather than a question in a vacuum.

Conditional example (adapt to your project):

1. “I do feature X in product Y. Audience is Z. Business purpose is A.”
2. “The main task of the user in this feature is B. The script begins with C and ends with D
3. “Numbered the minimum set of screens and states required for this flow. For everyone, the purpose of the screen and the key action
4. “What edge cases can I miss? Where does this type of flow usually break down

The output is a map of 5-9 screens with marks. I’ll transfer it to FigJam or directly to the comments on future frames.

### What to ask AI besides the Flow itself

At the same step, while the context is loaded into the models, I squeeze the maximum:

• What data is needed on each screen and where it comes from
• What empty states and mistakes are mandatory
• What microcopies (buttons, labels) fit the tone of the product
• What are 2-3 alternative solutions to this flow in the industry

It saves you another hour of work later when you sit over an empty button and think about what to call it.

---

## Step 2: Frame in Figma (30 minutes)

Then I go to Figma and collect a wireframe frame on the screen map. Principally without visual - gray blocks, placeholders, basic components from the system.

### Why the frame, and not immediately hi-fi

The framework answers one question: “Does logic hold?” Hi-fi answers ten questions at once, and none is normal. If you jump over the frame stage, you will control the arrangement of blocks with color, shadows and photos - and this is 3-5 times more expensive in time.

### What I do with my hands that I delegate to AI

Hands:

• Arrangement of screens on canvas according to the logic of flow
• The basic hierarchy of each screen (what is important, what is secondary)
• Links between screens by arrows

AI/plug-ins:

• Filling with fish text that looks like the truth (not Lorem Ipsum, but realistic names, amounts, statuses)
• Repeating cards with variable content
• Icons-stubs in meaning, not the “first one”

### Anti-patterns in the frame stage

• **Spend time on the grid and indentations. ** At this stage, they will be redesigned twice more.
• Do all the screens in the same detail. Key - in detail, the bandage - almost diagram.
• **Use real content. **Real texts take an hour to edit.

---

## Step 3: Script run and diagnosis (20 minutes)

The finished frame almost always looks logical - until you yourself go through it from the first click to the last. This step finds 70% of the holes before the stakeholder finds them.

### How to run a script

I put myself in the place of the user from the brief and go through the flow, saying aloud (or in notes):

• What do I see
• What do I wanna do
• Where to
• What I expect to see next

Every gap between “expecting” and “seeing” is a prototype bug.

### Questions for self-review

• Is it clear from the first screen where I went and why?
• Is there a way back at every step?
• What happens if the data doesn't come in, comes in empty, comes in wrong?
• Is there a state of “everything is done” and “nothing has begun yet”?
• What kind of screen will a user see when they return?

These five questions pull out almost all the typical omissions: missing empty states, dead-end screens, illogical transitions.

### Where to connect AI in the diagnosis

Feed models screenshots or description of the flow and ask:

• Find contradictions between steps
• List the states that are missing
• To formulate that in this float could not understand a beginner

AI here works as a second designer on a review - without ego, without fatigue and without "well, kind of norms.".

---

## Typical errors that cause the prototype to stall

### The designer makes the prototype for himself, not for the user

The most frequent failure. The prototype is beautiful, but it tests the taste of the author, not the hypothesis. The cure is to go back to the brief and ask yourself, “What answer do I want from this prototype?”.

### AI leads, designer goes

If you agree with the first version of the model, the prototype becomes average in the industry. AI generates the familiar well, the specific poorly. Specific is your area.

### The prototype breaks away from the design system

Do "out of the system" faster for a couple of hours. Transfer to the development - more expensive for a week. If there is a UI whale in the product, the prototype is assembled from it from the first minute, even during the frame stage.

### Too many screens

A 30-frame prototype almost always means you’re prototyping a product, not a hypothesis. You need 5-9 screens, the rest is tied with links or static pictures.

---

## Segment summary

The speed of a prototype is not “quickly press in Figma.” This is a brief brief brief to yourself, a structural dialogue with AI before opening the layout, a frame without a visual and running the script before showing anyone. AI speeds up each of these steps, but it doesn’t replace any of them—it works as an assistant while you’re driving.

## Advanced Scenarios: When Basic Workflow Is Lacking

A simple prototype covers 70% of tasks in two hours. The remaining 30% are special cases in which the standard path stalls. It is useful to know them in advance, so as not to build the process from scratch for each.

### Scenario 1: Prototype for research with users

Here, a cheap frame is not suitable - the respondent will respond to "curve squares" rather than a hypothesis. But photorealistic hi-fi is not necessary.

What's changing at workflow:

• The lyrics are real, not "plausible fish." Respondents read and make decisions about them.
• Error states, empty data and downloads are a must. They are specifically checked for interviews.
• Clickability only along the key path. The rest is a stub with the caption "not available in the prototype.".

AI in this scenario helps to quickly generate microcopy variants under different tones and then reduce them to one.

### Scenario 2: Prototype for budget protection

Stakeholder doesn't need 30 screens. It needs three keys: “before”, “after”, “effect”. Workflow is compressed to an hour and a half, but a separate step is added - packaging.

What is added:

• One slide with the problem in numbers from analytics.
• One screen with the proposed solution.
• One “how it works” scenario on a single user.

If you show more, you lose focus, the discussion goes into detail.

### Scenario 3: A prototype in someone else's design system

The most painful case is when you enter a project with a finished UI whale, which you see for the first time. The temptation to collect “in their own way” and then fit. It's not working.

The order is:

1. Half an hour to analyze the system: tokens, main components, navigation patterns.
2. The prototype is immediately out of the library, even if it's slower in the moment.
3. If the component is missing, you collect it from existing tokens, rather than bringing it from the outside.

AI is useful here to quickly describe the rules of the system in terms of screenshots – it saves reading documentation.

---

## Command and AI context

The prototype rarely lives on its own. Products, developers, and sometimes marketing. If the workflow is sharpened only for the designer, everything falls apart at the joints.

### What I put in the prototype for the command

• **Signatures on complex screens. ** One sentence: what is this state and when does it appear? The developer doesn't have to guess.
• **A list of open questions on the canvas. ** Not in the chat room, not in the task - next to the screen to which it relates.
• Verification by day, not by "final v2". Date is sufficient in the page title.

### How to share work with AI in a team

Inside the team, it is important that everyone understands where in the prototype “I thought” and where “the model suggested”. Otherwise, the review discusses the artifact of generation as a conscious decision.

A simple rule of thumb is that anything generated and not manually reflected is tagged. Gray background, ai-draft tag, separate layer - it doesn't matter. It's important that you see it.

---

## How to check the quality of the prototype

The prototype “works” is not “opens and clicks.” It's a set of measurable traits.

### Readiness checklist

• Each key screen answers the question “What is the user doing here?” in one verb
• There are three states of every important screen: empty, normal, error-free
• The path from the first click to the result is placed in one scheme
• There are no screens on the canvas to which no arrow leads
• Texts on key screens are read aloud and do not stumble
• You can see which components are from the design system, which are stubs

### Review questions with the team

• What hypothesis is this prototype testing, and how do we know it's confirmed?
• What is not possible in the current sprint and why?
• What data is needed on each screen and where does it come from?
• Where in the prototype do you, as a developer, not understand what is going to happen?

If the answer to any of the questions, “I don’t know,” isn’t a failure, that’s the next challenge.

---

## How to explain the decision to the team

The main mistake at the show is to drive the cursor on the layout and tell what is drawn. The team already sees it.

It's more useful to show three things:

1. Hypothesis. What do we want to know or confirm.
2. Forks. Where there were two ways and why this one was chosen.
3. Risk zones. What is the weakest in the prototype and where are we waiting for feedback.

This display takes 10 minutes instead of an hour and leaves the team with specific tasks, rather than the overall “seems beautiful.”.

## The anti-patterns I catch over and over again

Prototyping with AI breaks down not on complex cases, but on the same habits. They are easier to see in others than in myself, so I keep the list in front of my eyes.

### "I'll collect it first, I'll think about it later."

The most frequent. You open Figma, you draw blocks, after forty minutes you realize that you do not know what hypothesis you are testing. Next, the retrofit is included: you come up with an explanation for what has already been drawn. AI only reinforces this – the model will dutifully throw up five more options for what is not needed at all.

Healing one question before the first frame is what I want the team to understand by looking at it in two hours.

### Polishing instead of checking

The prototype does not yet answer the main question, but icons and shadows have already been selected. The review discusses radii, not logic. It's a convenient way to hide: visually ready, it's like the job's done.

The rule is simple: until the end-to-end scenario is passed at least once, no visual grinding.

### Blind trust in AI draft

The model produces a convincing in shape screen that seems correct. On the review it turns out that it is confused roles, there is no state of error and invented a component that is not in the system. If this screen is not marked as a draft, in a day it will become a “source”.

### Prototype without an exit point

Click, click, and at some point the script ends in nothing: no success, no error, no return. Testing this is pointless – the user will just run into the void, and you decide that this is a “user problem”.

### One prototype for all tasks

The same file is used for scratching, for budget protection, and for development. In the end, it's not good for anything: too detailed for the stakeholders, too raw for the developer, too confusing for the user on the test.

Better three short prototypes for three audiences than one universal.

### "AI will do anything, I'll just collect it."

The temptation is to assemble a screen of ten AI fragments and glue together. It turns out a visually coherent, but logically ripped artifact: the tone of the voice jumps, the patterns do not match, the states do not fit. AI is good in pieces, but the composition is held by a person.

---

## Final checklist before showing the prototype

I walk through it literally points, not from memory. Memory lies in favor of what has already been done.

• One hypothesis is formulated, for which a prototype is assembled
• There is a through scenario from the entrance to the result without breaks
• All key screens have three states: empty, normal, error
• AI-generated chunks visually separated from manual solutions
• On the canvas there are no “hanging” screens without entrance and exit
• Controversial spaces and open questions signed next to screens
• The texts are read aloud, without stumbling and stationery
• It is clear that from the design system, and what is a stub
• The prototype opens on the device on which it will be viewed
• It is clear in advance who and what decision will make after the show

If at any point the answer is "later" - it is better to postpone the display for an hour and close than take out the raw.

---

## Questions for a self-review

Before I call the team, I run the prototype through a brief internal analysis. This saves the most expensive resource – the attention of colleagues.

### In fact

• What will change if the hypothesis is confirmed? And if not?
• What's the cheapest way to test this without a prototype at all?
• What in this float did I not decide, but disguised with a beautiful screen?

### Uniformly

• Where did I choose visual over logic because it's faster?
• What three screens can you throw away without losing meaning?
• What can I not explain to the developer without the reservation “well, here conditionally”?

### The AI part

• What decisions did I make and what decisions did I make from the model?
• What would I not draw with my hands if I were drawing from scratch?
• Where did AI close a hole in my understanding of a task that needed to be closed with a mirror?

The third block is the most unpleasant, so it is important to set it.

---

## Short practical outcome

Two hours per prototype is not about the speed of the hands or what AI does for you. It's about the discipline of problem-setting and the rigid separation of what you want to check from what you want to draw.

Workflow is based on three things: a clear hypothesis to the first screen, AI as a draft with mandatory manual editing, and an end-to-end scenario that can be shown without comment. Everything else – settings for a specific project, team and design system.

If you remove one of the three, two hours turn into two days, and the prototype into a beautiful picture that you can't make a decision on.