How to get good website design from AI: from brief to working interface
Neaptide · September 20, 2026 · 13 min read · Updated: October 3, 2026
A practical guide to briefing AI, comparing layouts, choosing images and checking a website interface, with prompts and a fictional workshop example.
On this page

“Build a beautiful, modern website” leaves too many decisions to the model. The model does not know who will visit the page, what they need to understand or what information will help them decide. Without that, even an impressive mockup is hard to judge. It can look appealing and still fail at its job.
So before the first mockup, prepare the page content, set the visual rules and decide how you will assess the result. The steps below are written for small business owners, product managers and designers building a website with AI.
What to take from Anshu Chimala’s approach
In How to turn your AI into a world-class designer, Anshu Chimala recommends exploring creative directions, developing the strongest one and refining it through iteration. Among his techniques are a separate AI critic that sees only a screenshot, with none of the development history, and image generation steered by a specific creative concept.
This is one author’s practical advice, and his demonstrations do not promise the same quality for every project. Be most wary of a score such as “9 out of 10” from another model. It can help you compare versions. It cannot tell you whether a visitor will manage their task.
Our running example is a fictional lamp repair workshop. The briefs, mockups and situations below are teaching examples. We ran no user tests on them and measured no business outcomes.
Start with the visitor’s decision
For the workshop, “generate enquiries” is too broad a goal. Visitors need to know whether the workshop can handle their lamp, what to send for a preliminary assessment and how to get the item to the workshop. The page content follows from those questions.
Start with a short instruction:
We are designing a website for a lamp repair workshop. The visitor wants to know whether their lamp can be restored. The main action is to send photographs and a description of the fault for a preliminary assessment. Before doing so, they need to see the types of repair, the enquiry process and the conditions for accepting items. List the materials we need. Identify missing information separately. Do not invent prices, turnaround times, reviews or guarantees.A prompt like this exposes the gaps before layout work begins. If you do not know which items the workshop accepts or on what terms, ask the workshop. A handsome section built around an invented promise only postpones the problem.
The same order, understand the problem first and develop solutions second, is built into the Design Council’s Double Diamond. Its four phases are Discover, Define, Develop and Deliver. Generating mockups covers only part of that process.
Write a brief that supports decisions
A useful brief ties the visual treatment to the content. A calm, object-led presentation would suit our workshop: large detail photographs, clear captions and a prominent “Send photos” action. That is our choice for this example. It is no universal style for service businesses.
| Part of the brief | Workshop decision | What to check |
|---|---|---|
| Main question | Can you repair my lamp? | The answer or next step is easy to find |
| Content | Repair types, examples and enquiry process | Every section contains real information |
| Visual focus | Photographs of objects and details | Images help visitors examine the work |
| Copy | Short explanations without trade jargon | Visitors know which photos and details to send |
| Main action | Send photos for an assessment | The button opens the right form or contact channel |
| Limitation | A preliminary estimate is not the final price | The distinction is explained near the enquiry action |
Do not let the brief turn into a long list of bans. “No cards” says nothing about how useful the page will be. Cards can work well for a list of services. What matters is what they say and whether visitors can compare it.


Compare options using the same content
Prepare one set of headings, services and images before comparing layouts. If one version has strong copy and detailed photography while another uses placeholders, you are comparing several variables at once.
For the workshop, consider three ways to organise the material:
- By type of fault. Visitors recognise their situation and move on to the enquiry conditions.
- By restoration example. Real projects and explanations of the work become the page’s foundation.
- By repair process. The page explains the journey from the first photograph to collecting the repaired item.
The three options differ in the logic of presentation, so there is a real choice to make. Page density, image sizes and typography come afterwards.
Prepare three page outlines based on these three principles. Use the same source information and main action. For each outline, explain which question it answers first and what information appears further down. Do not add decorative effects yet. Flag any missing materials that prevent a decision.The three original mockups below explore the same subject. The first foregrounds faults, the second the object itself, and the third the enquiry process. Their palettes and compositions differ too, so read them as illustrations of possible directions. This is no controlled experiment. To test structure alone, keep the styling and content identical.



Ask someone who was not involved in the design to find out which items the workshop accepts and what they should do next. If they cannot, go back to the structure. Which colour they prefer is a separate conversation.
Can a random string help generate ideas?
If the options look too similar, an unusual source of associations may help. Chimala suggests generating a random string with an external script and using it as a starting point for design. Treat it as an experiment you can happily skip.
Sakana AI researchers describe a method called String Seed of Thought: the model first generates a random string itself, then derives its answer by performing operations on it. They study how well models follow probabilistic instructions and how diverse their output is. The method needs no external generator, which is where it differs from Chimala’s practical variation.
None of this shows that a random string makes a website easier to use or lifts sales. For a working project one simple test is enough: did the experiment produce an option that serves the task and is worth developing further? If not, set it aside. Novelty alone is no reason to replace understandable navigation.
Choose images according to their role
A photograph of a repaired lamp shows what the workshop can actually do. A generated image proves nothing of the kind, because there is no real order and no completed repair behind it.
Sort the images by purpose. A portfolio needs genuine photographs with permission to use them. An original diagram can explain how to make an enquiry. A conceptual illustration can set the mood or serve as a cover, provided its origin is stated.
Before generating an image, decide where it will sit. If a heading sits next to it, look at the two together. If it will be cropped on a narrow screen, make sure the important detail stays in frame. Keep text, buttons and service conditions as ordinary page elements so they can be edited and adapted separately from the illustration.
For the example project, the instruction could be:
Create a diagram explaining how to request a preliminary lamp assessment. Three steps: photograph the whole object, take a close-up of the damage, and describe what is not working. Keep captions as ordinary page text. Do not present invented workshop projects as its portfolio.
Turn feedback into verifiable changes
“This looks cheap” does not tell anyone what to change. Useful feedback names the place, the problem and how things should behave once it is fixed.
| General impression | Actionable revision |
|---|---|
| The page is too busy | Identify sections that repeat information. Suggest what to combine and explain what will be retained |
| The button gets lost | Check whether visitors can find photo submission after reading the conditions. Show an option with the action beside them |
| It is awkward on a phone | Check the form at a narrow width: labels, wrapping, keyboard, error messages and submission |
| The photos do not help | State what each photo explains. Replace vague captions with concrete descriptions of the work |

You can ask AI for a preliminary review. Give it the visitor’s task, the brief and the current screen. Ask it to separate visible problems from assumptions that can only be tested on a working website. A screenshot is enough to discuss composition. It cannot tell you whether the form submits.
Keep a short change log: what you observed, what you changed and how you checked it. For example: “The fault description disappeared after a failed submission → retained the entered text → repeated the failed submission and confirmed the description remained.” A record like that is worth more than a rising beauty score.

Test the interface where people will use it
Before launch, complete the main journey end to end. For the workshop, that means finding the conditions, preparing photos, filling in the enquiry, correcting an error and receiving a clear confirmation. Do not stop at the happy path. Empty fields and failed uploads need a clear response too.

Check separately that the text is easy to read and the controls are easy to hit. WCAG 2.2’s level AA contrast criterion requires at least 4.5:1 for normal text and 3:1 for large text, subject to specified exceptions. Large text means at least 18 pt, or 14 pt when bold. Measure contrast from the actual text and background colours. Judging by eye will not do.
For pointer targets, level AA criterion 2.5.8 sets a minimum of 24 × 24 CSS pixels. There are exceptions, among them smaller targets with enough space around them and links inside a sentence. This is a floor. The criterion does not advise making every button exactly that size.
Passing these two checks does not mean the page conforms to the whole standard. Go through it with a keyboard as well, and see whether focus is visible, fields are labelled and the layout survives enlarged text. Then give someone from your audience a specific task and do not coach them. Note where they hesitate and what they read differently from you.
Decide when to stop refining
For the first version, write down in advance what counts as done. Visitors can find the repair types and the terms for accepting items, understand which photos and details to send, complete an enquiry, keep their input after an error and receive confirmation. One more condition: every published promise matches how the workshop actually works.
Once those conditions are met, tie further changes to observations. If people confuse the preliminary estimate with the final price, rewrite the explanation. If a photo will not attach, fix the form. Another shade can wait.
Start with one journey and get it working. The next conversation with AI then has something definite in it: a problem you can point to and a way to check whether it has gone.
- Build a business website with AI: from the brief to testing enquiries
- Website development at Neaptide
Sources
- Anshu Chimala — How to turn your AI into a world-class designer, Lenny’s Newsletter, 1 September 2026. Original article. Only the publicly accessible portion was used; the subscriber-only continuation was not reviewed.
- Design Council — The Double Diamond. Process description. Supports the distinction between understanding a problem, developing options and testing solutions.
- Kou Misaki, Takuya Akiba, Sakana AI — String Seed of Thought: Prompting LLMs for Distribution-Faithful and Diverse Generation. Method and experiments. Source for output diversity and probabilistic instructions.
- W3C — Understanding SC 1.4.3: Contrast (Minimum). Text contrast.
- W3C — Understanding SC 2.5.8: Target Size (Minimum). Target size and exceptions.
Sources checked on 3 October 2026. The workshop brief, prompts, tables and diagrams were created for this article. They set out a proposed workflow and should not be read as an experimental report.