October 23, 2026 · 4 min read

The Dangers of Trusting AI With Your Products' Design and How to Prevent Them

Cover for The Dangers of Trusting AI With Your Products' Design, showing a cracked glowing cube and AI tool icons

"Your subscription has been cancelled."

That's what the screen told a customer on a product I reviewed this year. Eleven days later, their card was charged again. The cancel page looked great. Claude designed it and the team shipped it fast, but no one checked or stress tested what happened after someone pressed the cancel subscription button.

Everyone wants to talk about how fast AI can build, and how you don't need a designer or developer. And it is fast, but it won't ask what should happen when a card gets declined, a reset link expires or a customer cancels. It just guesses, and it guesses with total confidence.

Trusting AI with your UI is fine. Trusting it with your UX is how you lose customers.

What is the difference between UI and UX?

UI is what your customers see, like the words, buttons and colors. UX is what happens to them after they press the button.

Claude is great at UI (if you have a low bar) because UI is made of screens. UX is made of decisions, and if nobody on your team writes those decisions down, Claude makes them for you. That's the UI vs UX gap, and it's where AI-built products break.

Why is it dangerous to trust AI with UX?

AI never says "I don't know." If your prompt doesn't say who can see a customer's data, Claude picks something. If it doesn't say what a declined card should do, Claude picks something again. On a live product, one bad pick reaches every customer at once, and your customers will notice before your team does.

What does it cost a live product?

It costs more than the refund. The customer who got charged after cancelling doesn't just want their money back. They file a chargeback, write the support ticket in all caps and tell everyone in their group chat. Your churn goes up, your support team spends the week apologizing, and next sprint's features wait behind the fix.

It hits activation too. If a new user finishes sign-up and isn't sure it worked, they leave. Then someone on your team suggests spending more on ads. Please don't, because you'd be pouring water into a bucket with a hole in it.

Why your team can't catch it

You and your team are the worst people to test what Claude built, because you already know where every button is. You click through the demo, everything works, and it ships.

Your customers don't know where anything is. They switch from phone to laptop, let links expire and type their email wrong. They also have old accounts, unpaid invoices and teammates with fewer permissions.

How to prevent it before your next release

(steal these for your next standup)

Ask your team these six questions before any feature Claude helped build goes live. If the room goes quiet on one, that flow hasn't been tested.

  1. What does a new user see right after they sign up, and how do they know what to do next?
  2. What happens when a card is declined halfway through checkout?
  3. When a customer cancels, does billing stop, and do they get a confirmation?
  4. What does the page say when someone clicks an expired password reset link?
  5. Can a customer, or a teammate with fewer permissions, ever see data that isn't theirs?
  6. Has someone tested every email the product sends by hand, so no customer gets ten emails at once?

Then hand the feature to someone who has never seen it, like your newest hire or your mom, and watch them use it without helping. Every question they ask you is a decision Claude guessed at.

How we check what Claude builds

At Chayland Design, we start with those six flows, because they decide activation, revenue and trust. Before your team builds another screen, we write down what each flow should do when something goes wrong, so Claude, or a developer, doesn't have to guess.

Then we try to break your product as every kind of user, from brand-new trial users to admins. When something breaks, we fix the rule behind it so the problem doesn't come back next release. We test in phases alongside your team, so you keep shipping at Claude speed.

What checking gets you

On a connected fitness launch, the onboarding we designed and tested held up through more than 7,000 preorders. For an AI startup, we reworked the path from sign-up into the product, and new users reached their contacts in under two minutes.

You can let Claude draw the screens, but don't let it decide what happens to your customers. If you'd like a second set of eyes on what your team is shipping, our Clarity Audit walks through these flows with you, and what you pay for it goes toward your first month of design work.

Your customers will test your cancel button eventually. The only question is whether your team does it first.

Frequently asked questions

Is UI or UX more important?

UX matters more if you want to keep your customers. A plain product that works will outlast a beautiful one that charges people after they cancel.

Can AI replace a UX designer?

AI can replace a lot of screen drawing. It can't decide what your product should do when things go wrong, and that's the part customers remember.

How do you test features built with Claude?

Start with sign-up, payment, cancellation, password reset, permissions and emails. Try each flow the right way, then hand it to someone who has never seen it and watch them try.

Keep reading

Have a project in mind?

Let's build something obvious

Tell us what you're building. We'll tell you the clearest way to ship it.