A UI mockup is a picture of a finished product, not a description of one. An image model asked for “a login screen” returns a poster of a login screen; asked to show a shipped app, it returns something with a grid you can trace.
This guide is about the brief: what to decide before the prompt, which documented controls fit which decision, and how to repair one label without losing the layout.
Decide what the mockup is for
Most disappointing UI images fail for a reason unrelated to the model: the person asking wanted an editable design file and got a picture.
- A generated mockup is a raster image. It is not a layered, editable, component-based file, and no documentation claims otherwise
- That makes it right for proposals, landing-page heroes, covers and style alignment — anything a reader looks at rather than builds from
- It is wrong for handoff to engineering, where someone needs to move a button by four pixels
- The tools ranking for this keyword are vector editors, and their selling point is precisely what an image model does not do
Everything below assumes you are making an image of an interface, not a spec for one.
Write the brief as a shipped product
Six lines beat six paragraphs. Write them down, then translate them into one prompt.
- Screen and device — “one mobile screen, portrait”, stated as a noun
- Layout skeleton — the regions and their order: “status bar, headline, three list rows, bottom bar”
- Element count — a number, not an adjective; “three rows” and “several rows” give different images
- Label list — the exact strings that will appear in the screen, and nothing else
- Palette and weight — how many colours, and which element is largest
- Exclusions — no invented logos, no extra icons, no unlisted text, no device frame unless you asked
Anything you leave unspecified gets filled in for you, and invented lettering is the most common defect.
Fix the frame with aspect ratio and sketch
Two documented controls do most of the layout work.
- GPT Image 2.5 generates images in any aspect ratio: use the aspect ratio picker, or state the ratio in the prompt
- State it anyway — describing a tall single-column screen and also picking a portrait ratio is how you keep the two from fighting
- Sketch lets you draw in ChatGPT as a reference for the final image, the cheapest way to show where regions sit, as we cover in drawing with Sketch in GPT Image 2.5
- Sketch is a mobile-app feature; on the web you describe the skeleton in words
- A rough sketch of four boxes beats two sentences of layout description almost every time
If the layout is the hard part, sketch the layout and describe only the content.
Keep the text inside the screen short
Text rendering is a documented improvement in this generation, and the release lists sharper detail among its gains. No accuracy figure is published, so treat every string as a risk.
- Put labels inside the image and prose outside it: the caption or the article carries the explanation
- Prefer nouns and numbers to sentences — “Sign in” and “3 items” survive; a twelve-word marketing line usually does not
- When a string must be exact, quote it in the prompt and repeat it as a list, so the model sees the same characters twice
- Navigation labels, buttons and field names are where a typo shows most, so re-read those at full size
For work where the lettering carries the message, see text rendering in GPT Image 2.5.
Hold one product across a set of screens
A single screen is easy. Three screens that look like one product is the job.
- Generate the first screen, then feed it back as a reference for the next one instead of describing the product again
- OpenAI states the improvement directly: the model is better at working from reference photos, and distinctive features are more likely to carry through
- Keep the differing part in one place — the same prompt, one line changed per screen — so a mismatch is easy to spot
- This is the same problem as keeping a character recognisable, which we walk through in holding one subject across a set
Two worked examples: an app screen and a dashboard panel
Both briefs use the six lines above. Run them as written, then change one line at a time.
- Mobile screen (portrait, one column). Prompt: “A single mobile app screen, portrait 9:16. Top to bottom: a slim status bar, a bold headline reading ‘Today’, three equal list rows with a small square thumbnail left and two short labels right, then a wide primary button labelled ‘Continue’. Off-white background, one accent colour, thin grey dividers, flat vector style. No device frame, no extra icons, no text other than the labels listed.” Check the result in this order: are there exactly three rows, are the labels spelled correctly, and is the largest element the row stack rather than an icon.
- Desktop dashboard panel. Prompt: “A desktop dashboard panel, landscape 16:9. A wide header bar with a short title on the left, then a two-by-two grid of equal cards. Each card: a large short number, one caption, and a simple line or bar chart. Captions: Sessions, Signups, Revenue, Churn. Light grey background, one accent colour, thin borders, no text other than the five labels.” Check whether the four cards are genuinely equal, whether all five labels appear, and whether any card has been replaced by decoration.
Both examples are deliberately label-light: explanation belongs around the image, not inside it.
Repair one label without redrawing the screen
Regenerating a whole screen to fix a typo is how layouts get lost.
- Comments can be placed directly on an image for more focused editing, the documented way to point at one region
- The second documented route is to describe the change in the conversation panel without the selection tool
- OpenAI states the limit plainly: highlights are not always precise and edits may extend beyond the area you selected, so verify neighbouring regions after every fix
- Undo, Redo and a Cancel that starts over are what make one-label corrections safe to attempt
We walk through the workflow in comment editing in GPT Image 2.5.
Where UI mockups still break down
Plan for these, because no prompt removes them.
- Dense copy inside the screen: the more prose you put in, the likelier a word is misspelled
- Repeated components drift: check identical cards one by one rather than the group
- Exact brand lettering: generated wordmarks are reconstructions, not the real asset
- Precision edits: corrections are documented to sometimes spill past the area you marked
- Small type below roughly caption size is a coin toss, whatever the release notes improved
The honest workflow is two passes: brief and generate, then correct the labels. Control details are in the GPT Image 2.5 overview.
Frequently asked questions
Can GPT Image 2.5 produce an editable design file?
No. It produces an image. Layered, component-based files come from vector design tools, and no OpenAI documentation claims otherwise. Use the mockup for proposals, not for engineering handoff.
How do I keep three screens looking like one product?
Generate the first screen, pass it back as a reference for the next, and change one line of the prompt per screen. The release notes state the model is better at preserving subjects from reference images.
Should I write every label in the prompt?
Yes, and quote the strings exactly, then repeat them as a list. Keep each short, and re-read navigation labels and buttons at full size.
Can I fix one misspelled label without regenerating?
That is what comments on the image are for. Mark the region, describe the correction, then check the areas around it — OpenAI states edits may extend beyond the selection.