Designing AI Interfaces: Five Patterns I Learned While Building MAIA

When we started designing MAIA, an AI travel and concierge assistant, a chat interface seemed like the logical choice.

Everyone understands chat. You type something, AI replies. Job done. Except it wasn’t that simple…

Once we started working through real travel scenarios, it became obvious that putting a chat box on the screen doesn’t magically create a useful AI product. The real work was helping people express what they wanted, giving the AI the right context, and turning its answer into something they could actually use.

Along the way, a few design patterns kept appearing. Some worked. Some looked good in theory but fell apart in real scenarios. These are the five I would take into my next AI project.

AI-Solution-Canvas Download

Pattern 1: Scaffold the blank state

We often assume that people know what to ask AI. Most of the time, they don’t.

They don’t know what the assistant can do, what information it has, or how specific their question needs to be. Then we give them an empty field with “Ask me anything” and expect magic to happen. In an early beta sample, many people opened the chat and left without asking anything. The sample was small, so I wouldn’t make dramatic claims from it. Still, the signal was hard to ignore.

Maybe they had no reason to use it. Maybe they opened it by accident. Or maybe the blank chat simply didn’t give them enough confidence to start.

This is where quick prompts helped.

A useful quick prompt does more than save typing. It shows what the assistant can do and gives the user a low-risk way to test it. They can try something, inspect the answer, and decide whether they trust the system enough to continue.

The pattern is not “add a few random prompts under the input.”

The pattern is to give users a relevant and easy starting point based on where they are and what they may want to achieve.

Pattern 2: Make suggestions situational

At one point, we had a rule that every response should include a follow-up question and quick prompts. It sounded great in a meeting. In the actual experience, it often made no sense.

The follow-up question pushed the conversation in one direction, while the quick prompts suggested three others. Instead of helping the user, we gave them another small decision to make.

Sometimes the AI should ask a question because important context is missing.

Sometimes it should offer a few clear options.

Sometimes it should provide a CTA.
…

And sometimes it should just answer the question and stop talking.

Good AI patterns become bad when we use them as fixed templates. Suggestions should respond to the user’s situation, not to a requirement that every answer must contain another interaction.

Not every answer needs to become a conversation.

Pattern 3: Design around skills, not personality

“AI travel assistant” sounds good, but it doesn’t tell you much.

Can it recommend a destination? Can it check availability? Can it reserve a table? Can it show live prices? Can it contact reception? Or can it only explain how the user can do those things?

These are different skills.

Defining them turned out to be one of the most important parts of the work. Each skill needed its own inputs, context, trusted data, response structure, limitations, and possible next action. This became especially important when we introduced CTAs.

The assistant might recommend a restaurant, but that doesn’t necessarily mean it can book a table. It might describe a resort, but that doesn’t mean it knows the latest availability. Without clear boundaries, we end up with an assistant that sounds very confident while being unable to finish the job.

Personality is nice. Clear capabilities are more important.

The pattern is to define what the AI can understand, what it can answer, what it can do, and when it needs help from another system or a person.

Pattern 4: Reveal information progressively

Restaurant recommendations gave us another problem.

If we provided too little information, the suggestions felt generic. If we added more context, the user got a small essay about five restaurants when they probably just wanted to know where to eat. We spent time looking for the perfect answer length. Eventually, it became clear that there wasn’t one.

The better solution was to show information in layers.

Start with a short overview. Show the important differences and briefly explain why each option might fit. If the user wants opening hours, directions, menus, or dietary information, let them go deeper.

This sounds obvious when written down. Still, AI products often place everything in one answer simply because the model can generate it.

Just because the AI can write six paragraphs doesn’t mean anyone wants to read them.

Progressive disclosure also makes corrections easier. If one part of a recommendation is wrong, users should be able to adjust that part. They shouldn’t have to regenerate the entire answer and read everything again.

Pattern 5: Design trust into the whole system

One of MAIA’s strongest use cases was bringing together information that users would otherwise struggle to find.

Instead of searching through different pages and documents, a user could ask a question and receive a clear summary in their own language. This worked surprisingly well, including in languages that were not officially supported by the app. But then people started asking reasonable questions about prices, daily schedules, availability, maps, and local policies.

That is where things got interesting.

The AI could be excellent at finding and explaining static information, but it didn’t always have access to current operational data. Sometimes a link didn’t work. Sometimes local staff gave the user different information. The user doesn’t care whether the problem came from the model, an outdated document, a broken link, or a missing API.

For the user, the AI gave the wrong answer.

Trust is therefore not a message under the input field. It is a design pattern that affects the entire system.

It includes:

using reliable and current sources;
separating static knowledge from live information;
providing actions and links that actually work;
explaining why something was recommended;
being honest when information is uncertain;
allowing users to correct the system;
and providing a clear route to a person.

Handing a conversation over to a human is not necessarily a failure. Sometimes it is the most useful and trustworthy thing the AI can do.

The anti-pattern: Chat as the whole product

If I started another AI product tomorrow, I would not begin with the question, “What should the chat look like?”

I would ask:

What is the user trying to achieve?
What does the system already know?
Which skills can the AI perform reliably?
Which information needs to be live?
How can the user refine one part of the result?
What action should follow a useful answer?
When should the AI stop?
When should a person take over?

My biggest lesson was simple.

A good AI interface is not the one that creates the longest or most impressive conversation. It is the one that asks the least effort from the user and still gets them somewhere useful.

Everything else is just a very polite chatbot.