Using affordance to design intuitive AI agents

Voice AI agents are the most human-sounding technology we've ever put on a phone line, and that's precisely what makes them hard to use. The more human-like an AI agent sounds, the more capable callers assume it is.

In my work as an Agent Architect at Parloa, I've seen this disconnect derail interactions time and again: the AI voice agent opens with a broad, "How can I help?" and the caller, suddenly on the spot, doesn't know where to start. Or when the agent asks for a phone number, the caller provides a few digits before pausing for the "uh-huh" they'd get from a human. The agent may sound conversational, but the caller still needs cues that explain what it can do and how to interact with it.

This isn't just a UX argument: it's a business one. When callers don't know how to interact with an agent, they might escalate unnecessarily, or leave without completing their task. That can mean lower containment rates, higher operational costs, and frustrated customers that don’t buy again.

To reduce the disconnect between what callers expect and what the agent can do, we need to design these interactions with affordance in mind.

The designer's lexicon for an old problem

The concept of affordance comes from ecological psychologist J. J. Gibson, who used the term to describe the actions an environment makes possible for a particular actor. A chair affords sitting; a handle affords grasping or pulling. Don Norman later adapted the concept for design in The Design of Everyday Things, arguing that an action being possible isn’t enough. People also need perceptible cues to understand what they can do, and they interpret those cues through their own prior experiences and culture.

The way we help users perceive what they can do with an AI voice agent is by giving them those cues: what Norman called signifiers. Signifiers can prime a user on what or how they can do something (feedforward), or point them toward why something didn't work and how to fix it (feedback). By using signifiers to show callers the agent’s constraints, we help them build a mental model of how to interact with the technology.

It's all in your head

Callers bring habits shaped by years of interacting with older automated systems. As Larissa Specht explains in “The caller’s register: Why language habits outlast the technology that created them,” many have learned to compress their requests, front-load keywords, or offer minimal context. These strategies helped them navigate rigid IVR systems, but may work against more conversational AI agents.

Those learned habits are only part of the challenge. The phone call is an unforgiving medium, with no text to read at your own pace, no conversation log to scroll, no visual aid. During a conversation, callers must hold what they’ve just heard in working memory while interpreting it and preparing a response. That capacity is limited, and the demand increases as agent responses become longer or introduce multiple instructions, choices, or pieces of information. Without visual support, callers can’t just look back at what they missed; they must remember it or ask the agent to repeat it.

The more we reduce that cognitive load by offering precise signifiers at the right moment rather than front-loading every piece of information at once, the more intuitive the conversation feels, and the more likely callers are to reach their desired outcome. The goal is to give callers the information they need when they can act on it.

The following patterns show how signifiers can guide callers through different stages of a conversation, from the opening prompt to error recovery:

Tell the caller what the AI agent can do

Agent: Hello, and welcome to Kronos Insurance. I’m your digital assistant. How can I help you?

Caller: Um, I want to know if anything has been done about the claim I filed?

“How can I help?” sounds natural and signals that it’s the caller’s turn to speak. But when the agent’s capabilities are narrower than the question suggests, it doesn’t give the caller enough information to formulate a useful response. The caller must guess what the agent can handle and may discover its limitations only through trial and error.

A short description of the agent’s scope can act as a signifier:

Agent: Hello, and welcome to Kronos Insurance. I’m your digital assistant. I can answer questions about your coverage, help you file a claim, or check the status of an existing claim. How can I help you?

Caller: What's the status of the claim I filed?

The revised opening does two things. First, it names a small set of supported tasks, giving the caller a clearer picture of the agent’s scope. Second, phrases such as “check the status of an existing claim” model how the caller can express a request. The list should be brief and representative rather than exhaustive; otherwise, the signifier becomes another source of cognitive load.

Signal when it’s the caller’s turn

In a face-to-face conversation, people use pauses, intonation, eye contact, facial expressions, and body language to judge when someone has finished speaking. A phone call preserves the audible cues but removes the visual ones. With an AI agent, it may be even harder to tell whether the system has finished, is processing, or expects a response.

When the agent needs input, a clear call to action (CTA) signals that the caller’s turn has begun. That cue can be a question or a direct instruction:

Caller: What's the status of the claim I've filed?

Agent: I’d be happy to help you with that. Could you please tell me the claim number?

Or:

Caller: What's the status of the claim I've filed?

Agent: I’d be happy to help you with that. Please provide your claim number.

Both responses make it clear that the agent expects the caller to speak and identify the information it needs. One uses a question; the other uses a direct instruction. The grammatical form matters less than whether the caller understands what to do next.

There are moments when an additional prompt would be counterproductive. If a caller asks the agent to wait while they find a document, for example, a simple acknowledgment is enough: “Of course. Let me know when you’re ready.”

The caller has already indicated how the next turn will begin. The agent’s behavior must also support that by allowing enough time and avoiding repeated interruptions. There’s no universal wait time. Teams should base it on how long callers typically take for that task, then test when a neutral check-in becomes helpful rather than disruptive. A message such as, “I’m still here, take your time” can reassure the caller without forcing the next conversational turn.

Show callers how to provide complex inputs

Long numbers expose another difference between human and machine conversation. When people give a number to another person, they often divide it into smaller groups and wait for brief confirmation before continuing:

Human agent: Please tell me the claim number.

Caller: My claim number is 0349.

Human agent: Mm-hm.

Caller: 5736.

Human agent: Okay.

Caller: And then 1726.

These short acknowledgments tell the caller that the other person has understood each part and is ready for the next one. An AI agent may handle the same exchange differently. A pause might trigger endpointing before the complete number arrives. Even when the full turn is captured, automatic speech recognition (ASR) can struggle with long digit sequences. The prompt should therefore reflect how the agent is configured to collect and validate the information.

If the agent expects the complete value in a single turn, for example, the prompt should make that expectation clear before the caller begins. This is feedforward:

Agent: Please say the full 12-digit claim number without pausing.

Caller: My claim number is 034957361726.

The signifier should reflect the system’s actual behavior and be validated through testing and conversation data.

When things go wrong, guide. Don't blame.

"Conversation designers design for the unhappy path." is a well-worn saying in this community, and a true one. The happy path shows what an agent can do when everything goes as expected. Recovery shows how well the interaction supports callers when it doesn’t.

To go back to the Kronos Insurance example, suppose contract numbers begin with 03, while claim numbers begin with 16. After the caller provides a number beginning with 03, a generic error response might be:

Agent: I’m sorry, but I couldn’t find a claim with that number. Please provide the correct claim number.

This tells the caller that the attempt failed, but it doesn’t explain how to correct it. A more useful response provides feedback and a path forward:

Agent: I couldn’t find a claim with that number. Claim numbers begin with 16, and you can find yours in your claim confirmation. Please say the claim number when you’re ready.

The revised response communicates the relevant constraint, explains where to find the requested information, and makes the next action clear. It doesn’t characterize the caller’s input as careless or wrong; it gives them what they need to continue.

If the system can reliably identify the number as a contract number, the response can be even more specific: “That appears to be a contract number. For this request, I’ll need the claim number that begins with 16.” The feedback should never claim to know more than the system has established.

Not everything, everywhere, all at once

By now, a pattern should be emerging: We’re adding signifiers without flooding the caller with information. Each cue appears when it becomes useful, and not a moment sooner. This is progressive disclosure: revealing guidance or options as the caller needs it instead of explaining everything upfront.

Consider Dual-Tone Multi-Frequency (DTMF) input: the ability to enter information using a phone’s keypad. When the agent supports it, keypad input gives callers an alternative to speaking. But there’s usually no reason to introduce that option at the beginning of the call. It becomes relevant when voice input isn’t working:

Caller: My claim number is 1624…

Agent: I only caught part of the claim number. If it’s easier, you can say the full number again or enter it using your keypad.

Here, keypad input is the affordance, and the agent’s spoken instruction is the signifier that makes it apparent. Introducing the option at the point of difficulty keeps earlier prompts focused while giving the caller another way to continue.

As with every signifier, the wording must match the system’s behavior. The agent should only offer keypad entry when it’s enabled, and the prompt should explain any requirements, such as the expected number of digits or whether the caller needs to press a confirmation key.

Treat every signifier as a hypothesis

The work doesn’t stop once a signifier has been written into the conversation. A signifier is useful only if callers perceive it, understand it, and respond as intended. Each design choice should therefore be treated as a hypothesis and evaluated through both quantitative and qualitative evidence.

Quantitative measures can show where an interaction may be breaking down. Containment provides a broad view of whether callers are completing their tasks, but it should be considered alongside transfers, drop-off points, repeated intents, reprompts, invalid inputs, and task completion. A spike in failures after the claim-number prompt might indicate that the feedforward is unclear, that the input collection isn’t working as expected, or that callers don’t have the requested information available, for example. The metric identifies a place to investigate, but it doesn’t explain the cause on its own.

Qualitative analysis helps answer why. Reviewing recordings and transcripts can reveal hesitations, interruptions, partial responses, misunderstood prompts, and the language callers use to repair the conversation. Together, the quantitative and qualitative views help teams determine whether the wording needs to change, the system behavior needs to change, or both.

If callers navigate an interaction smoothly without a CTA at the end of every turn, don’t add one simply because a design rule says you should. If they struggle despite clear instructions, changing the words alone may not solve the problem. Follow the evidence and update the hypothesis accordingly.

When reviewing a conversation, ask three questions:

• Does the caller know what this agent can do?

• Do they know what to do next?

• When something goes wrong, do they know how to recover?

A “no” to any one of them tells you where the conversation still needs work.

But the answers won’t stay the same. As people interact with AI agents more often, their expectations of what those agents can understand and do will change. Some cues that help callers navigate AI interactions today may eventually become unnecessary. As agents evolve, designers will need new ways to make their capabilities clear and show callers what to do next. Conversation design has to evolve with both the technology and the people using it.