Designing AI features for people who didn't ask for AI: lessons from VOCHI, Tattoon and Intch

Short answer: most people don't want AI. They want a result: a video that looks great, a tattoo idea they would actually wear, the right person to meet. Good AI UX treats the model as an implementation detail and designs around that result: show outcomes instead of technology, give people a starting point instead of a blank prompt, let them steer and retry, be honest about time and quality, and keep them in control.

Do users actually want "AI" in my app?

I've designed three consumer products where AI did the main work, and in none of them was "AI" the thing people came for.

• VOCHI was an AI-powered video editing app with AI video effects. I worked on early product development and led UI for iOS and Android. It became App of the Day on the App Store in 126 countries and was later acquired by Pinterest. People wanted a video that looked impressive.
• Tattoon is an AI tattoo generator I co-founded and designed from scratch. UX research and design improvements raised engagement by 35%, and the AI generation mechanics I designed raised retention by 28%. People wanted a tattoo idea that felt like theirs.
• Intch was an AI-powered networking app that introduces people to relevant contacts. My onboarding redesign improved activation by 20%. People wanted the right introduction, not a matching algorithm.

The pattern is simple. The more an interface talks about AI, the more it asks the user to care about how something works instead of what they get. These are the principles I design by now.

1. Show the result, not the model

People judge an AI feature by its output, and they decide whether to try it by the output they see before they start. So the first screen should show what's possible: real examples of results, close to what this user might make.

Model names, "powered by" badges and sparkle icons don't answer the user's question. "What will I get, and will it be good?" does. I label AI where it changes how people should treat the result (it may be wrong, it's a suggestion, it used your data), not as decoration.

2. Solve the empty prompt problem

A blank text field that says "Describe what you want" looks like freedom. For most people it's homework. Jakob Nielsen calls this the articulation barrier: prompt-driven interfaces require users to put their needs into well-written prose, and many people can't do that easily.

Most people recognize what they like faster than they can describe it. So I design the first step as choosing, not writing:

• styles, examples or presets to start from;
• a few tappable suggestions that build a prompt for the user;
• "make one like this" from an existing result;
• a free text field as an option for those who want it, not the only door.

3. Let people steer and retry

Generation is probabilistic. The first result is a draft, and the interface should treat it that way. Retry should be cheap and guilt-free. Variations should sit next to each other so people can compare. Changing one thing ("same, but smaller", "different style") should not mean starting over. Earlier results should stay available, because people often realize the second option was the best only after seeing the fifth.

Google's People + AI Guidebook frames this as feedback and control: users should be able to shape the output and see that their input changes something. A person who steers a result owns it. A person who just receives one judges it.

4. Set expectations about time and quality

AI is often slow by interface standards. Nielsen's response-time limits put the edge of attention at about 10 seconds, and many generations take longer. Silence during that time reads as "broken".

What I do instead: say up front roughly how long it takes, show progress that means something, let people leave and come back to a finished result, and use the wait to show what's being made. Quality needs the same honesty. The PAIR guidebook suggests an onboarding formula I like: this is the product, it helps you by doing X, right now it can't do Y. Telling people the limits early costs a little excitement and saves a lot of disappointment.

5. Make failure graceful

An AI feature will produce bad results. The design question is what happens next. A bad output should never be a dead end:

• keep everything the user entered;
• say what likely went wrong in plain words, without blaming the user;
• offer the next step: try again, adjust one setting, pick a preset;
• give a way out that doesn't involve AI at all, when there is one.

The Errors + Graceful Failure chapter of the same guidebook makes a point I agree with: what counts as an error depends on what the user expected. Many "AI failures" are expectation failures that a single sentence earlier in the flow would have prevented.

6. Build trust through control and transparency

The goal is not maximum trust. The PAIR guidebook calls it calibrated trust: people should know when to rely on the system and when to use their own judgment.

In practice that means a short reason next to a recommendation ("suggested because you both work in health tech" reads very differently from a bare match), clarity about what personal data the feature uses, and the user always making the final call: accept, edit, dismiss, undo. In social and networking products this matters twice, because a recommendation is also about another person.

AI onboarding: get to the first result fast

For AI products, onboarding is where most of the value is won or lost. The model can only help after it has something to work with, so it's tempting to ask for everything up front. I do the opposite:

• ask only what the AI needs for the first result, and say why you're asking;
• show a real result as early as possible, even an imperfect one;
• teach features in context, when they become useful, not in a tour before anything has happened.

Onboarding, activation and retention are where I've done my strongest work, and the lesson holds every time: activation comes from the first moment of value, not from explaining how clever the system is.

A checklist before you ship an AI feature

1. Can a new user see an example of the result before doing anything?
2. Can they start without writing a prompt?
3. Is retry one tap, and are earlier results kept?
4. Do they know how long it will take and what to expect from quality?
5. Does every failure keep their input and offer a next step?
6. Can they see why the system suggested something, and say no?
7. Does the copy talk about their result rather than about AI?

FAQ

How do I design AI features that users trust?

Aim for calibrated trust, not blind trust. Explain why the system suggested something, be clear about limitations and the data it uses, and let users accept, edit or reject every result.

Should I tell users that a feature uses AI?

Yes, when it changes how they should treat the result: it might be wrong, it's a suggestion, or it uses their data. Don't use "AI" as the main selling point; lead with what the person gets.

How do I add AI to an app without confusing users?

Attach it to a task people already have, show example results first, replace the blank prompt with presets and suggestions, and keep a non-AI path where possible.

What makes good onboarding for an AI app?

Getting to a real result fast. Ask only for the input the AI needs, explain why, show an output early and teach the rest in context.

---

Alla Kuchynskaya is a Senior Product Designer and AI Product Builder with 12+ years in startups. She led UI for VOCHI (App of the Day in 126 countries, acquired by Pinterest), co-founded and designed the AI tattoo generator Tattoon (+35% engagement, +28% retention) and redesigned onboarding at Intch (+20% activation). She works part-time, full-time or per project, remotely from Bali. Portfolio: alla.studio · Telegram: @aladesigner.