How to Make Claude Designs Look Less AI-Generated

To make Claude designs look less generic, give it a real user task, approved content and a small set of specific layout and visual constraints. Review the rendered result, then revise one problem at a time instead of asking it to “make it less AI.” fenbs can retain the tested design prompt and the standards a person has approved for future iterations.

A convincing interface expresses the purpose of the product. A repair appointment page needs clear dates and contact details; a research library needs scanning and filtering. Decorative choices cannot compensate for a page that ignores what its users came to do.

What should you specify before Claude makes a layout?

1. Define the person and task: who uses this screen, what they need to do and what information helps them decide.
2. Provide real headings, labels, sample records and realistic content lengths. Mark any missing material clearly.
3. Name the primary action and the secondary information. Explain which content should receive attention first.
4. Set a visual direction with reasons: typography, spacing, colors, imagery and the amount of decoration that fits the brand.
5. Request one screen first, including its phone layout and an important non-ideal state, before expanding the design.

Imagine a small architecture studio showing project inquiries. The important information might be the client, location, proposed work and next contact date. Asking for a “premium dashboard” leaves Claude free to invent summary charts and decorative cards. Supplying the actual records and review task gives the design something concrete to organize.

Anthropic’s frontend prompting guidance↗ (opens in a new tab) acknowledges that vague direction can lead to generic design patterns. The practical response is a specific visual and functional brief, followed by inspection of the result.

What design prompt can you adapt?

Design one screen for [person] who needs to [task].
Use the supplied content and records; do not invent statistics, testimonials or product capabilities.
Primary action: [one action].
Information order: [what matters first, second and third].
Visual direction: [specific references or a short description, with reasons].
Reuse these existing elements: [type, colors, spacing and components].
Layout constraints: [content width, navigation, density and phone behavior].
Avoid decorative elements that do not help this task. Do not place every section in an identical card.
Include: a realistic full state, an empty state and a clear error state where relevant.
Before expanding the work, explain the main layout choice and show the first screen for review.
Content and examples: [approved material].

For an existing product, supply its actual components and design rules before asking for novelty. A different typeface on every new screen can make a product less coherent. For a new product, choose a small visual vocabulary and test whether it works across ordinary content, long labels and narrow screens.

References should explain a quality rather than invite a copy. You might like one page’s generous text spacing and another’s compact navigation. State those reasons, then ask for a layout suited to your content. The reference’s brand, wording and exact arrangement need not become yours.

Which constraints reduce the generic look?

Avoid treating familiar components as evidence of bad design. A clear button or a common navigation pattern can be exactly right. The issue is whether Claude selected the component because it serves the task or repeated the same attractive arrangement regardless of the content.

Once a person accepts the direction, save the reasons as well as the visible choices. In fenbs Decisions and rules, “project images lead; avoid decorative metrics because visitors need examples of our work” is more useful to the next assistant than “make it elegant.”

How do you critique a rendered design?

Inspect the actual page at phone and desktop sizes. Start with the reading order and primary task, then check content, spacing and visual details. A screenshot can reveal hierarchy, but interactive behavior also needs to be exercised. Do not approve a form merely because its empty state looks polished.

• Can a new visitor tell what this page is for and what to do next?
• Does the layout still work with long names, missing images and realistic records?
• Are labels, helper text and error messages close to the things they explain?
• Can you use the important controls with a keyboard and identify the current focus?
• Does the phone version preserve useful content without tiny text or page-wide scrolling?

The W3C’s accessible design guidance↗ (opens in a new tab) covers contrast, clear controls, labels and layouts for different screen sizes. Its page structure tutorial↗ (opens in a new tab) explains how meaningful structure supports navigation. Use these as practical checks alongside the visual critique; a distinctive interface still needs to be usable.

Give feedback with a location and intended result: “On the phone layout, put the appointment date before the description so it is visible sooner.” Ask Claude to preserve the approved parts. Rebuilding the entire screen after every comment makes it harder to know whether the specific problem was fixed.

What should remain a human design decision?

A person should choose the tradeoffs that define the product: what users need most, which brand direction fits and whether the result is ready to release. Claude can propose alternatives and explain their consequences. A confident explanation is still a proposal until the responsible person accepts it.

Do not let the urge to look distinctive introduce fictional proof, unusable navigation or unnecessary motion. Test the ordinary path first. Then consider whether an illustration, transition or unusual composition improves understanding or creates a useful impression for this audience.

For the product-specific design workflow, see Claude Design. For a wider quality process, see making Claude design better. Writing tone is a separate concern covered by making Claude sound less AI; this page focuses on the interface people see and use.

If you hand the accepted design to a different coding assistant, preserve its content and layout constraints with the handoff. The Devin versus Claude Code comparison covers that separate tool choice. Changing the assistant should not quietly reopen the design decisions a person already approved.

How to do this with fenbs

1. Create a free account and add the product or website project.
2. Save the tested design prompt in Skills and prompts. Include the user task, content requirements and visual constraints.
3. Record the standards a person approves in Decisions and rules. Keep proposed alternatives open until someone chooses.
4. Add tasks for the screens and review issues. Keep each current plan, acceptance check and remaining uncertainty with its task.
5. Connect Claude, ask it to read the relevant project context before designing, and save progress before the next session takes over.

fenbs does not render or evaluate your interface, and it does not replace a design tool or usability review. If you only need one visual experiment, saving its prompt locally may be sufficient. Use the shared record when approved standards must guide repeated work. The AI prompts topic has other focused instructions.