Web Design · Pages & layout
The Best Prompt for Wireframing
The best prompt for wireframing keeps the model at low fidelity and makes it rank content before arranging it. This prompt takes one screen, the user's goal and the content that must appear, then returns a priority order, a text wireframe, a block-by-block specification with real labels, the screen's other states and an alternative layout to compare. Colors, fonts and imagery are deliberately excluded.
Wireframing Prompt
Produces a low-fidelity wireframe of one screen as a text diagram and block spec, with content priority, states and annotations and no visual styling.
- Works with
- ChatGPT, Claude, Gemini
- Difficulty
- Beginner
- Complexity
- Multi-part reply
- Variables
- 6
- Version
- 1.0
Customize this prompt
Fill in what you know. Anything left blank stays as a [bracketed placeholder]. Nothing you type leaves your browser.
6 variables · fields marked * matter most
# Role You are a UX designer producing a low-fidelity wireframe. Your concern is structure: what is on the screen, in what order, and what each part does. Visual styling is out of scope. # Screen brief Screen: [Screen] What the user came here to do: [What the user came to do] Content and controls that must appear: [Content and controls that must appear] Viewport: [Viewport] Deliverable: [Deliverable] Constraints: [Constraints] # Steps 1. Priority. Rank every item in the content inventory from most to least important for the user's goal. Mark anything that can sit behind a tap, a tab or a scroll. 2. Layout. Arrange the screen in zones that follow the ranking. State the reading order in one sentence. 3. Wireframe. Draw or outline the layout in the deliverable format requested. For a box diagram, use plain ASCII characters inside a code block, keep it under 64 characters wide for mobile and 100 for desktop, and number each block. If both viewports are requested, produce one wireframe for each. 4. Block spec. For each numbered block give: its purpose, the exact labels or sample content, the control type (button, link, text input, select and so on), and what happens on interaction. 5. States. Describe how the screen differs when it is empty, loading, showing an error, and showing a success message. Skip any state that cannot occur and say why. 6. Annotations. Add notes a developer would otherwise have to ask about: defaults, validation, truncation of long text, focus order. 7. Alternative. Offer one structurally different layout in three or four sentences, with the trade-off against your main version. # Boundaries - No colors, typefaces, icon styles, imagery direction or brand language. - Use realistic labels and sample data. No lorem ipsum and no placeholder such as "Title here". - Include only what is in the content inventory. If you think something is missing, list it under "Suggested additions" at the end and leave it out of the wireframe. - The primary action must be reachable without hunting; say where it sits and why. - Where you had to guess at behavior, mark it [ASSUMPTION]. # Output format Seven headings matching the steps, then "Suggested additions" if needed. Use a table for the block spec.
Use it when you are
- Sketching a screen's structure before opening a design tool
- Agreeing on content priority with a client or product owner
- Giving a developer an annotated layout for an internal tool or admin screen
- Comparing two structural approaches to the same screen quickly
Why this prompt works
Ranking happens before arranging
Most weak wireframes fail on hierarchy, not on boxes. Step one makes the model order the content by its value to the user's goal and decide what can be tucked away. The layout that follows has a stated logic you can agree or argue with, which is the real purpose of a wireframe review.
Styling is ruled out explicitly
Left alone, a model will describe gradients and friendly sans-serifs. Listing colors, type and imagery as out of scope keeps the response at the fidelity where structure is cheap to change, and stops reviewers reacting to taste before the layout is settled.
A diagram and a spec, numbered to match
ASCII boxes show spatial relationships at a glance but cannot hold detail. The numbered block table carries labels, control types and behavior. Because the numbers line up, a reviewer can point at block 4 and everyone knows what is meant.
States and an alternative are part of the job
Empty, loading and error conditions are where real screens tend to break, and they are usually forgotten in a first sketch. Asking for them, plus one structurally different option with its trade-off, gives you something to compare instead of a single answer to accept or reject.
Additions are quarantined
Models like to be helpful by adding features. Routing those ideas to a separate list keeps the wireframe faithful to your inventory while still letting you see what the model thought was missing. You decide what gets promoted into the next version.
How to use it
- Pick one screen. For a multi-screen flow, run the prompt once per screen and keep the block numbering separate.
- Write the content inventory as a plain list of things, including the data shown for repeated items such as cards or rows.
- Choose the mobile viewport first unless the screen is desktop-only; narrow layouts force clearer priorities.
- Read the priority ranking before the diagram. If the order is wrong, correct it and ask for the wireframe again.
- Copy the block spec into your design tool or ticket as the starting annotation set.
- Review the Suggested additions list with your team and add accepted items to the inventory for the next pass.
AI model compatibility
| Model | Status | Notes |
|---|---|---|
| ChatGPT | Expected to work | View the ASCII wireframe in a code block with a monospaced font. If the boxes look misaligned, ask for the diagram again at a narrower width. |
| Claude | Expected to work | If you paste a long content list or requirements document, put it in <content> tags, in line with Anthropic's guidance on separating material from instructions. |
| Gemini | Expected to work | If the box diagram is hard to read, switch the deliverable to the annotated text outline; the block spec carries the same information. |
“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.
Worked example
Scenario: A yoga studio adding class booking to its web app.
# Role You are a UX designer producing a low-fidelity wireframe. Your concern is structure: what is on the screen, in what order, and what each part does. Visual styling is out of scope. # Screen brief Screen: Class booking screen for a yoga studio web app What the user came here to do: Find a class this week and book a spot in under a minute Content and controls that must appear: Week date strip Class list: class name, start time, duration, teacher, level, spots left Filter by level Filter by teacher Book button per class Waitlist option when a class is full Link to membership and credits balance Viewport: Mobile, about 360px wide Deliverable: ASCII box wireframe and annotated text outline Constraints: Must sit above the app's existing bottom tab bar; browsing does not require login, booking does # Steps 1. Priority. Rank every item in the content inventory from most to least important for the user's goal. Mark anything that can sit behind a tap, a tab or a scroll. 2. Layout. Arrange the screen in zones that follow the ranking. State the reading order in one sentence. 3. Wireframe. Draw or outline the layout in the deliverable format requested. For a box diagram, use plain ASCII characters inside a code block, keep it under 64 characters wide for mobile and 100 for desktop, and number each block. If both viewports are requested, produce one wireframe for each. 4. Block spec. For each numbered block give: its purpose, the exact labels or sample content, the control type (button, link, text input, select and so on), and what happens on interaction. 5. States. Describe how the screen differs when it is empty, loading, showing an error, and showing a success message. Skip any state that cannot occur and say why. 6. Annotations. Add notes a developer would otherwise have to ask about: defaults, validation, truncation of long text, focus order. 7. Alternative. Offer one structurally different layout in three or four sentences, with the trade-off against your main version. # Boundaries - No colors, typefaces, icon styles, imagery direction or brand language. - Use realistic labels and sample data. No lorem ipsum and no placeholder such as "Title here". - Include only what is in the content inventory. If you think something is missing, list it under "Suggested additions" at the end and leave it out of the wireframe. - The primary action must be reachable without hunting; say where it sits and why. - Where you had to guess at behavior, mark it [ASSUMPTION]. # Output format Seven headings matching the steps, then "Suggested additions" if needed. Use a table for the block spec.
What a good response should contain
- A ranking that puts the date strip and class list first and moves filters behind a single control
- A numbered ASCII diagram narrow enough to read on a phone-width code block
- A block table with real sample data, such as a class name, time and spots left, and the behavior of the Book button when the user is logged out
- State descriptions for a day with no classes, a full class showing the waitlist option, and a failed booking
- One alternative layout, for example a calendar grid, with its trade-off on small screens
This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.
Testing and editorial review
Status: Untested. Reviewed for structure and clarity by the editorial team. No recorded model test yet.
No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.
| Author | TheBestPromptFor Editorial Team — The editorial team writes, reviews and maintains the prompts and guides on TheBestPromptFor. Prompts are drafted with AI assistance and reviewed against published editorial standards. |
|---|---|
| Published | November 15, 2026 |
| Last reviewed | November 15, 2026 |
| Last tested | Not yet tested |
| Version history |
|
Limitations and things to check
- ASCII diagrams are approximate. They show order and grouping, not real proportions or spacing.
- The model cannot test whether the layout works for users; treat it as a proposal to review and prototype.
- Complex screens such as dashboards and data tables may exceed what a text diagram can show clearly. Split them into regions.
- Behavior marked [ASSUMPTION] needs confirming with whoever owns the product rules.
Alternative prompts
Web Design
Complete Website Design Prompt
A structured brief that walks an AI model from business goals to sitemap, page layouts, visual direction and responsive rules.
- ChatGPT
- Claude
- Gemini
Web Design
Landing Page Design Prompt
Plans a single-goal landing page: message match with the traffic source, section order, first-screen spec, form design and draft copy using only your real proof.
- ChatGPT
- Claude
- Gemini
Web Design
Responsive Design Prompt
Turns one page layout into responsive rules: content order on small screens, fluid techniques, justified breakpoints and a per-component behavior table.
- ChatGPT
- Claude
- Gemini
Related resources
Guide
How to Improve AI Responses
A diagnostic approach to weak AI answers: name the fault, trace it to the gap in your prompt, then follow up precisely or rewrite and start again.
Technical guide
Prompt Chaining: Breaking a Task Into Linked Prompts
How to split a large task into a sequence of focused prompts, design the handoffs between them, and debug the chain when a step goes wrong.
Frequently asked questions
Can a text-based model really produce a wireframe?
It can produce the thinking a wireframe records: priority, grouping, labels and behavior, plus a rough box diagram. That is often enough for an early review or as a brief for a design tool. It is not a substitute for a drawn layout once spacing and proportion start to matter.
Can I turn the output into a Figma or other design-tool wireframe?
Yes. Use the numbered blocks as frames and the block table as annotations. Some design tools and plugins can generate layouts from a text description; if you use one, paste the block spec, since it is more precise than the diagram.
Why does the prompt forbid colors and fonts?
Because feedback follows whatever is most visible. If a wireframe carries style, reviewers discuss style. Keeping it bare holds attention on whether the right things are on the screen in the right order, which is the decision that is expensive to change later.
Sources and references
- Prompt engineering overview — Anthropic
- Prompt engineering guide — OpenAI
Was this prompt useful?
No account needed. Do not include personal information.