What I Learned Building With Claude · Post 6 of 12

Making AI-Built UI That Doesn't Look AI-Built

Pete Griffin, Digital VisionJune 2026

There's a tell. If you've used enough AI-generated interfaces you start to recognise it: the cards all have the same radius, the font is a system serif that nobody chose, the spacing feels like it was assigned by a loop rather than a judgment. Everything is present and nothing lands. It looks like a wireframe that got mistakenly shipped as a finished product.

The problem isn't that the AI can't build UI. It can, quickly and abundantly. The problem is that it has no aesthetic stake in the result. It will produce whatever the component library defaults to unless you fight it into having opinions. Left uncorrected, it will give you a functional dashboard that feels like something generated for a demo, not something a real user will trust their work to.

I've built a lot of dashboards and embedded widgets over the past two years. Here are the moments that taught me to fight back.

1.The blank first screen nobody understood

I launched an app dashboard and immediately walked it through as a first-time user. What I saw was a blank form. No explanation of what the app did, no indication of where to start, nothing to tell me whether I was in the right place at all. The AI had built what I asked for — a settings form — but it had no idea that a real person opening this for the first time had no idea what any of it meant.

The whole onboarding section was rebuilt around use-case cards: flat panels that described what you could achieve, in plain language, targeted at the people who'd actually be using it. Demo content you could try before filling anything in. A "start blank" escape hatch buried at the bottom where it belonged. The form didn't move. The context around it changed everything.

The default AI response to "build an onboarding flow" is another form with a progress bar. That's not onboarding. Onboarding is telling someone why they're here and giving them a reason to stay.

The rule: before you ship any first screen, walk through it as a stranger. Cover your prior knowledge of what the app does. If the screen doesn't orient you in under ten seconds, it needs more context, not more fields.

2.The animation that looked spectacular on a Tuesday afternoon

I was building a hero widget — a fullscreen visual that lives behind a site owner's headline. The early direction was ambitious: 3D scenes, path tracer rendering, HDR images loaded from external CDNs, audio reactivity, all of it. The path tracer converged beautifully. After about two seconds.

The problem is that nobody sees your second frame. The first frame is everything. A widget with a loading state and a convergence arc is a widget that looks broken for the first second of every page load. I scrapped the entire direction and started over with a single fullscreen shader that renders complete on frame zero. Calm. Colour-field. No dependencies. Nothing to load, nothing to break, no external URL to 404.

The second lesson from this project was restraint. The AI will suggest effects because you asked it to make something good, and effects feel like good. But a hero widget is atmospheric backing — the user's heading and call-to-action are the actual hero. Anything in the visual that competes with the copy has already failed. Slow motion, subtle colour shifts, a ten-second breath cycle. That's the standard that the best software companies use. None of them have a path tracer behind their homepage.

The rule: first-frame quality beats peak quality. If the visual improves after it loads, redesign it so the final state is already there on frame one. Restraint is not a compromise — it's the aesthetic choice that most AI-built UI never reaches.

3.The colour palettes that were technically correct and felt wrong

I was building a set of client-facing documents — project plans, status updates, automation breakdowns. The AI naturally reached for teal. Teal is the safest colour in the world: inoffensive, slightly professional, used in roughly half of all enterprise software. Nobody ever got fired for teal.

The problem is that a brand is nothing if it's whatever the AI defaults to. The established palette — navy, warm gold, deep purple — exists because those choices say something specific. Swapping in teal doesn't make the document wrong; it makes it generic. Generic earns less trust than something that clearly belongs to somebody.

Same story with typography. The AI's default serif is Times New Roman, or whatever the system fallback happens to be. Forcing a specific typeface is a one-line CSS override. It's not a large ask. But it has to be explicit, because the AI will always take the path of least resistance — which is the path every other AI-built interface is already on.

The rule: defaults are the enemy of identity. Name the font, name the palette, name the specific values. If you want something that looks like it was designed rather than generated, you have to bring the designer's specificity. The AI brings the output; you bring the decisions.

The pattern underneath

Three different surfaces — a dashboard, an animated widget, a document — and the same failure each time: the AI built what was asked, not what was needed. It filled the functional specification and left the aesthetic judgment empty. That gap is exactly where "looks AI-built" comes from.

The fix is always the same: bring the decisions yourself, in advance, with specifics.

it, not just the fields they'll fill in

values, the exact spacing system — and audit it yourself before anything leaves your hands

The AI is extraordinarily good at executing on specifics. What it cannot do is decide that specifics matter. That part is yours.

Next in the series · Post 7 of 12
Giving an AI a Memory: Building a Second Brain