AI Product Design: How to Design AI Features People Trust

AI product design is the work of designing products and features where a model, not a fixed rule, decides part of what the user sees: a generated thumbnail, a suggested title, an extracted insight, an agent's next step. It uses the same craft as any product design (research, flows, interface, testing), but the hard problem moves. The screens are rarely the hard part. Trust is. Users have to understand what the AI did, believe it enough to act, and stay in control when it is wrong. I have designed AI products twice in very different settings: a no-code NLP platform for financial organizations at Accern, and a suite of AI thumbnail and title tools at ViewStats, the creator platform built by the team behind MrBeast. This guide is what both taught me, turned into principles, a process and patterns you can use.

It is long on purpose. If you only need one idea, take this one from my ViewStats case study: the biggest challenge was not designing the interface, it was designing trust.

What is AI product design?

Classic product design assumes the system is predictable. Press the button, get the same result every time. AI product design starts from the opposite assumption. The output changes, it is sometimes wrong, and the user often cannot see why it came out the way it did.

That changes three things about the job.

You design for a range of outputs, not one. A generated thumbnail can be great, mediocre or embarrassing. The interface has to work for all three: let users compare, retry, edit and discard without friction.

You design the relationship, not just the screen. Will users rely on it too much, too little, or just right? Google's People + AI Guidebook calls this calibrating trust, and it is the right frame. Over-trust is as dangerous as distrust.

You design what the AI needs from the user. Data, permissions, context, examples. Many AI products fail before the model ever runs, because the user never connects the account or uploads the file that makes the AI useful.

An AI product designer is simply a product designer who is good at those three things, and who understands the material well enough to know what the model can and cannot do. If you want the broader role first, start with what a product designer does.

Why AI product design is really designing trust

At ViewStats, we designed and launched a new suite of AI creator tools: AI thumbnail generation, text-to-thumbnail, face swap, thumbnail variations, AI title generation and thumbnail testing workflows. The initiative moved from concept to launch in roughly two weeks. Most of the core experiences were designed, reviewed and shipped within a few days while engineering worked in parallel.

Speed was not the hard part. Creators were being introduced to a new way of producing content, and the product had to feel powerful without feeling intimidating. That is a trust problem dressed as a UI problem. You can read the full story, with the work I am allowed to show, in my ViewStats creator platform case study.

Then the second trust problem arrived, one that no interface could solve alone. Shortly after launch, the AI tools became one of the most discussed features in the creator ecosystem. Many creators were excited about faster workflows. Others raised concerns about what AI-generated thumbnails could mean for artists and thumbnail designers. The discussion spread across YouTube, social media and mainstream press, including BBC coverage of the ViewStats AI thumbnail tool. I wrote about that experience in depth in AI ethics in design: what the thumbnail backlash taught me.

The lesson I took: trust in an AI product has two audiences. The user in front of the screen, and the community around that user. Design for both, or the second one will design your launch for you.

Lesson two: an AI product nobody understands is a service with a login

Accern was a no-code AI platform that helped financial organizations extract insights from unstructured data for risk and investment decisions. I joined in January 2020 as the first design hire. The case study is on my Accern no-code AI platform case study page.

The model was not the problem. Understanding was. 95% of users never used the product by themselves; the customer success team built use cases for them. Terms like taxonomy, NLP and data store confused people who were experts in finance, not machine learning. And users had to move between two separate products, one for text analytics and one for predictive analytics.

We redesigned around one path and plain language, working through the customer success team because large finance enterprises were hard to reach for testing. The published results: retention up 200%, with users checking the product two to three times a week and navigating without help, and 82% fewer support tasks. The longer story is in enterprise UX design when 95% of users never used it alone.

What this means for AI product design: users do not need to understand the model. They need to understand what it does for them, in their own words. Every piece of model language that leaks into the interface is a small tax on trust.

Lesson three: show value first, ask for trust second

Most AI features need something from the user before they can help: an account connection, a file, a permission. At ViewStats, many creators signed up but did not connect their YouTube channel, even though it unlocked the most valuable features. Funnel analysis and research showed they did not understand what they would gain.

Instead of prompting harder, we redesigned around value communication: stronger onboarding moments, better empty states, contextual prompts and clear explanations of what creators would unlock. The channel connection rate went from 13% to 65%+. I broke that down in onboarding UX best practices from a 13% to 65% activation fix.

For AI products this is the most reusable pattern I know. Before you ask for data, show what the AI will do with it. A preview, a sample result, an example from a similar user. Ask for trust only after the user has seen why it is worth giving.

AI product design principles I use

These come from the two stories above, from building 17 AI experiments myself, and from public guidance like the PAIR guidebook. They are opinions with reasons, not laws.

1. Lead with the job, not the model

"AI-powered" is not a value proposition. "Get three thumbnail directions for this video" is. At ViewStats, research showed creators were not asking for more data; they were asking "What should I make next?" The AI features made sense only because they answered a question creators already had.

2. Keep the human as the author

Generate options, not verdicts. Variations, suggestions and drafts keep the user in the creative seat. That was the core of my position during the backlash: AI tools already existed everywhere, so the real design question was how to help creators move faster while keeping humans at the center of the creative process.

3. Make the output editable, not just regenerable

A regenerate button is a slot machine. An edit is a conversation. The best AI features let users fix the 10% that is wrong instead of rolling the dice on the 90% that was right.

4. Speak the user's language

The Accern lesson. Replace model vocabulary with the user's vocabulary, in labels, empty states and errors.

5. Design the failure states first

What does the screen look like when the model returns something useless, slow or off-brand? If the answer is "the user is stuck", the feature is not ready. Undo, retry, fallback to manual and clear limits are part of the core flow, not edge cases.

6. Be honest about limits

Tell users what the AI cannot do before they find out the hard way. Honest limits feel less magical in a demo and build far more trust in month two.

7. Think about who is affected but not in the room

Thumbnail designers were not ViewStats users, but the feature touched their work. Ask early: who outside the product will this change, and how would they describe it?

Principle	What it prevents	Where I learned it
Lead with the job, not the model	Features nobody asked for	ViewStats research: "What should I make next?"
Keep the human as the author	Users feeling replaced, community backlash	ViewStats AI thumbnail tools
Editable output	Endless regenerate loops	My AI experiments
Speak the user's language	Users depending on support to use the AI	Accern: 95% never used it alone
Design failure states first	Dead ends when the model is wrong	Every AI build I have shipped
Show value first, ask for trust second	Users refusing to connect data	ViewStats: 13% to 65%+ connection rate
Design for people outside the room	A launch that becomes the story	The ViewStats AI backlash

The AI product design process, step by step

My process for AI features is my normal product process with a few extra checkpoints. Here is the AI-specific shape.

1. Find the question users already ask. Interviews, support requests, community channels, analytics. At ViewStats that meant creator interviews, onboarding analytics, Discord feedback, support requests and internal workshops. The AI feature should answer an existing question faster, not invent a new one.

2. Map where the AI will be wrong. List the ways the output can fail: wrong, slow, generic, unsafe, off-brand. Each one needs a design answer.

3. Prototype with real model output, not lorem ipsum. A mockup with a perfect AI result lies to everyone. Real outputs show you the range you are actually designing for. This is where being a designer who can build pays off: I take a Figma frame, build it with Claude and the Figma MCP, and test against what the model really returns.

4. Design the trust moments. The first result, the first mistake, the first time the AI needs data or permission. These moments decide adoption more than any feature list.

5. Ship small, watch closely. AI features change behavior in ways you cannot predict from a prototype. Ship a narrow version, read the feedback channels daily, and adjust. At ViewStats the whole AI suite went from concept to launch in about two weeks, which is only safe if you keep listening after launch.

If you want to see how that third step works end to end, I described my setup in my AI design workflow from idea to App Store.

Common AI UX patterns and when to use them

Patterns are tools, not answers. Here is how I think about the ones I see most.

Chat. Great when the task is open-ended and the user knows what they want to ask. Poor as a default. Most users do not want to write a prompt to do something a button could do.

Inline suggestions. The AI proposes, the user accepts or ignores, inside the workflow they already have. Low friction, high trust. The ViewStats Chrome extension followed the same logic for insights: bring help into the place users already work instead of making them switch tabs.

Variations grid. Several outputs side by side. It turns judgment into the user's job, which is exactly where it belongs for creative work.

Preview before commit. Show what the AI will change before it changes it. Essential for anything that writes, sends, publishes or deletes. I made the same argument about agents publishing websites in Framer MCP and AI agents that can publish your site.

Explain on demand. A short "why this result" that users can open if they want. Most will not, and that is fine. The option itself signals honesty.

What makes a good AI product designer

If you are hiring for AI product design, or trying to become one, these are the skills I would look for. They overlap with any strong product designer, with more weight on a few.

Comfort with uncertainty. Designing for outputs you cannot fully control.
Research instincts. Finding the question users already ask, through whatever channel exists.
Language skills. Turning model concepts into the user's words.
Hands on the material. Enough technical fluency to prototype with real models. The design engineer role is where this is heading.
Judgment and ethics. Seeing who a feature affects beyond its users.
Taste in motion and feedback. AI is often slow and uncertain. Good loading states, transitions and feedback make waiting feel like progress. My experiments use physics, motion and sound for exactly that reason.

And a limit to all of this: if your AI feature is a thin wrapper around a model with no real job behind it, no amount of trust design will save it. Design starts with whether the feature should exist.

Go deeper

Related guides on this site, each one a piece of this pillar:

FAQ

What is AI product design in simple words?

Designing products where an AI model produces part of the experience, and making sure people can understand it, trust it the right amount, correct it and stay in control.

How is designing AI products different from regular UX design?

Regular UX assumes predictable outputs. AI UX has to work for good, mediocre and wrong results, design what the AI needs from the user, and manage how much users rely on it. The craft is the same; the risks are different.

How do you design AI features people trust?

Answer a question users already have, show value before asking for data, keep users as the authors with editable output, use their language, design failure states first, and be honest about limits. Then watch real usage closely after launch.

What does an AI product designer do day to day?

Research the job users need done, map how the AI can fail, prototype with real model output, design the trust moments (first result, first mistake, permissions), and work closely with engineers to ship and adjust. Increasingly, they also build prototypes in code.

Do AI product designers need to code?

Not always, but it helps more here than anywhere. Prototyping with real model output reveals problems a static mockup hides. My path from Figma to shipped code is in how to become a design engineer.

Will AI replace product designers?

It replaces parts of production. It does not replace the judgment about what to build, for whom, and what it does to the people around them. AI products make that judgment more valuable, not less.

If you are building an AI product and want it to feel trustworthy from the first screen, work with me as your AI product designer. I design it, prototype it with real model output, and help ship it.