Nielsen Norman Group publishes practical chatbot design guidelines
The Nielsen Norman Group released a new set of practical usability guidelines for designing chatbots this week. The piece argues that whether users actually rely on a chatbot, rather than abandoning it for a human channel, comes down to a small set of design decisions that most teams skip during the build phase.
The four design decisions NN/g flags
The guidelines focus on four areas where chatbot designs typically fail. The first is scope: bots that try to handle every possible query end up handling none of them well, because the natural-language understanding degrades with breadth. Bots that explicitly limit their scope ("I can help with order tracking and returns") perform better on user satisfaction than bots that promise general help.
The second is conversational repair — what the bot does when it doesn't understand. NN/g recommends a three-step pattern: acknowledge the confusion, offer two or three likely interpretations, and provide an exit to a human channel. Bots that ask the user to rephrase without offering options score lower on completion rates.
Escalation and trust
The third design decision is escalation visibility. Bots that hide the human escalation path produce frustrated users; bots that surface it from message one, even if the bot is the default first responder, build trust faster. The presence of a visible exit doesn't reduce bot usage — in NN/g's data, it actually increases it, because users will engage more willingly with a bot when they know they're not trapped.
The fourth is identity disclosure. Chatbots that pretend to be human, or that obscure their non-human status until pressed, produce worse outcomes than bots that introduce themselves clearly. The recommendation is to lead with the bot's identity and capabilities in the first message and let the user decide whether to engage.
Where the guidelines stop short
The piece is grounded in practical UX research, but it doesn't address the harder question of when chatbots are the wrong solution entirely. For some support scenarios — anything involving emotional weight, complex troubleshooting, or high-stakes decisions — the better answer is to skip the bot and route directly to a human. The guidelines assume a bot is being built; they don't help with the decision of whether to build one.
Still, for teams already committed to shipping a chatbot, the four design decisions are concrete enough to drive specific design choices, and the published research backs them up. Recommended reading for any team that owns a support surface.