What to ask yourself before building an assistant

Many assistant projects start with the technology: “we want an AI chatbot” or “we want a voice agent.” That’s understandable, because technology is the most visible part. But when you start there, it’s easy to end up with something that works in the demo and that nobody uses.

In July 2024, Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. Among the causes it cited poor data quality, poorly controlled risks, escalating costs and unclear business value (Gartner, 2024). You can see most of those causes coming if you ask yourself a few questions before building.

1. Which conversations do you want to have?

An assistant exists to hold conversations with your customers or users. It helps to start by knowing what kind:

Transactional: the goal is to get something done, like buying, booking an appointment or processing a refund. What matters is completing the task without errors.
Informational: the goal is to answer questions, like a website’s FAQ or a service’s opening hours. Here the quality of your content rules.
Entertainment or companionship: playing, learning, meditating. Pace, personality and wanting to come back are what matter. That’s the case of Diana, the meditation app we built with Grupo Planeta for Alexa.

Many assistants mix several types, but one is usually the main one, and that changes what needs the most careful design.

2. Where will the person be when they talk to it?

The same conversation succeeds or fails depending on the place. Bill Buxton, a researcher at Microsoft, proposed thinking in terms of place-onas, the equivalent of design personas but applied to places. Every place frees up or ties up your hands, eyes, ears and voice. In the car your hands and eyes are busy, but you can talk and listen. In a library, it’s the reverse (Intercom, 2017).

This question rules out ideas right away. A voice-answering kiosk in a library, where you have to be quiet, makes no sense. At a gas station, the noise would make it impossible to understand each other. When we designed the voice assistant for the patient rooms at Sanitas’s Valdebebas hospital, the context drove many decisions: a patient speaking from bed, who may not see the screen well, and for whom the call to the nurses has to work every time (Sanitas case study).

3. Through which channel, and in which mode?

There are many options today: a phone call, WhatsApp or another messaging app, your website or your own app, an assistant like Alexa, a device with or without a screen. And in each channel, the interaction can be spoken, written, or a mix of both with visual elements.

The useful question is where your customers already look for you. If most of them call, a chatbot on your website may not reach the people who need it most. If they message on WhatsApp, asking them to download an app adds an obstacle.

4. What kind of product do you need?

There are three paths, and they don’t cost the same:

Your own assistant, concentrating the essentials of your service. It’s the most ambitious path.
An extension of an existing assistant, like an Alexa app or an integration with another general-purpose assistant.
A conversational feature inside a product you already have: a help chat on your website or voice search in your app.

The third option often delivers more value with less risk, and it’s a way to learn before going for the first.

5. How will you know if it worked?

An assistant is an investment, and you have to decide upfront how it will be measured. Human-centered design usually looks at three things at once: whether it’s desirable for the people using it, feasible with the available technology and viable for the business (Explorer Labs).

For people: what problem it solves for them and whether it’s more convenient than what they do now. Sometimes the value lies in accessibility or in being available at any hour.
For the technology: whether the environment allows it (noise, connectivity, language) and which errors are tolerable.
For the business: what specific goal it pursues. Cutting costs is the knee-jerk answer, but it’s worth also thinking about resolving more cases the first time, reaching new people or providing better service.

If you can’t write in one sentence which number has to improve, you don’t yet know what you’re building.

6. What do you already know about how your users talk?

Before writing a single response, look at what you already have. Customer service conversations, emails, social media comments and what people search for on your website tell you what they ask, how they ask it and with which words. It’s the best raw material for design, and the source of the sentences you’ll later test the assistant with.

7. What can you test this very week?

The last question is the one that speeds things up most. In an interview with La Nave Nodriza about the workshop I teach, I summed it up like this: with prototyping, “you learn as soon as possible whether the product and the conversation work or not” (La Nave Nodriza, 2022, our translation).

A conversation is abstract until you hear it. A prototype lets you check whether the assistant’s question is understood the first time, whether the person takes too long to answer or whether visual support is needed. And it gets the whole team talking about the same thing: two people can be imagining different solutions to the same problem.

Today, with language models, a prototype that really converses can be put together in a few days. That ease has a catch: the prototype looks finished, and the step of testing it with real people gets skipped. That’s the step that teaches you the most.