Conversational UX Best Practices

Chatbots have existed among us for quite some time now. In 1964, Joseph Weizenbaum created ELIZA, widely known as the world’s first “chatterbot”. ELIZA used scripts and pattern-matching to simulate conversations between computers and humans, most famously mimicking a session between a human patient and a computer-simulated Rogerian psychotherapist. While Weizenbaum created ELIZA to demonstrate that computer ‘understanding’ of humans is just an illusion, it was still a great advance in the field. Since then, chatbots and AI have come a far way.

Bots and virtual assistants have become widespread and mainstream, but unfortunately the hype surrounding bots and AI hasn’t always quite lived up to expectations. Many of us have engaged with a chatbot expecting deus ex machina, but have instead been faced with something like this:

Conversational UX Best Practices

Poncho the WeatherBot Source

Nevertheless, chatbot popularity is very much on the rise and we’re learning more about how to make them better every year. Their popularity has created a new field of research interest: Conversational User Experience/Interface (CUX/CUI).

This field investigates the successes and failure of the chatbot interface, attempting to minimise places where users are getting stuck, confused or frustrated. A chatbot should always be a quicker, easier, and more engaging way for the user to achieve his or her goal. CUI/CUX research tries to find the best ways to do this.

At Atura we’ve been developing bots for a few years now. Here are some of the conversational UX best practices we’ve gathered along the way:

Some general things to keep in mind

  • Users don’t use bots for advanced Natural Language Processing (NLP) – they use them for ease of use, flexibility, efficiency, etc. NLP is an added bonus.

  • NLP is still restricted, and giving the illusion of high NLP just to be impressive will be frustrating for users when issues are encountered.
    • Users just want the bot to work
    • Avoid creating unrealistic expectations
  • A bot should be a better (quicker, more efficient, more fun) option than speaking to a human and using the webpage.

  • An aesthetically pleasing and minimalist design (in every aspect) is always favoured – every extra unit of information competes with and diminishes the visibility of others.
    • The fewer options the better
  • Always aim for discoverability and for the fewest clicks possible to achieve user goals.

Avoiding the tl;dr response

  • Walls of text to be avoided at all times (wall = more than 3 lines)

  • Maximum characters for one message: 90 characters (3 lines)

  • Preferable length of one message: 63 characters (2 lines)

  • When sending more than one message at once: maximum 140 characters in total

  • Maximum 2 messages at a time

  • Scrolling up to read a message is a tl;dr trigger
    • Test your bot on multiple platforms and devices to check that scrolling isn’t necessary
    • Account for keyboards which will be pulled up
  • Walls can be broken up by adding things like a “keep going” button



  • Use buttons as guardrails to keep user on the happy path
  • Remember that buttons give the illusion of limited choice
    • They discourage users from inputting text
    • Text input will need to be prompted
  • Make sure buttons remain functional, as users will often scroll up and re-click
    • Use disappearing buttons if you do not want users to re-click
  • Format the buttons in the 1st person narrative (from user perspective)
  • Restate the action in the button when confirming an action
    • [E.g. “Yes, delete location” and “No, keep location” instead of “yes” or “no”]


  • Over-impose personality onto user through ‘quirky’ button wording
    • [For example, choosing “no” is a better UX than choosing “no, I’m not that cool :disappointed:“]
    • However, entertaining but subtle phrasing can be better than just yes/no
    • Some recommend staying away from boring yes/no buttons, others encourage their use due to the small cognitive load they require
  • Give too many button options



  • Include the following in the introduction:
    • Indicate user is speaking to a bot
    • Introduce bot name as well as what bot does, usually by suggesting next step
    • If possible, a call to action. E.g. “Try it! Type xyz below”
  • Favour clarity over elegance
    • Using more common terms can help avoid semantic satiation when the term is used frequently
    • [E.g. users got confused between the more aesthetically appealing “outbound” and “inbound”. “Departure” and “return” worked better]
  • Confirm by asking, not stating
    • [E.g. “Yes, delete location” and “No, keep location” instead of “yes” or “no”]
    • Minimises annoyance, minimises misunderstanding
    • This should be followed by a confirm/undo button
    • When relevant, confirmations of user actions should also describe what the outcome will be [e.g. “If you delete this, ...”]
  • Be thoughtful about question phrasing
    • Don’t use a ‘what’ question when a ‘where’ question gets more to the point
    • [E.g. “what airport do you fly from?” was less successful than “where do you fly from?"]
  • Distinguish COMMANDS or key words from natural language through font style
    • Aids user in navigation
  • Always initiate dialogue and prompt user about functionality
    • This includes at the end of an interaction
  • Use personalised language where possible
  • Know your audience
    • Will you be writing in command line style, natural language, jargon, slang? What is appropriate?
    • Keep this consistent


  • Use open-ended questions (if possible)
    • This widens the margin for error
    • Always give options where possible o [E.g. “What colour?” vs “What colour? I have red, white...”]
  • Allow the conversation to steer too far off the happy path
    • Redirect towards functions
  • Switch up vocabulary or language style
    • The phrasing of key terms should not be interchanged with synonyms later in the flow
    • This is particularly true with button wording when it comes to options like going back, restarting, etc.
  • Express errors as codes
    • Errors should always be written in plain language, and followed by a suggestion for a solution
  • Show reader the same message repeated within a flow
    • Error messages/ prompts that may come up more than once should have randomised, alternate versions
    • [E.g. “Welcome back” as opposed to a second “hi” is a nice touch]
  • Use technical terms
    • If you wouldn’t say it yourself, the chatbot shouldn’t say it
  • Make messages too specific
    • An error message should be general enough to cater for anything that would trigger it
    • [E.g. Entering a string instead of a number, entering too few numbers, or entering gibberish would all trigger an error response in an ID number flow]
    • Responses to open-ended Qs should also cater for all possible inputs
  • Use UI-specific directions
    • UI can change
    • Refer to actions and concepts instead
    • [E.g. “Choose an option below” instead of “swipe and tap on an option below”]



  • Wait for user to stop typing before sending a response
    • When using text input, it is not unusual for users to send multiple messages
    • These should be interpreted as a single response
    • This is especially important when gathering parameters for intents
  • Include a wait time before sending responses, as well as in between a response with multiple messages
    • It is distracting to have bubbles popping up while the user is still reading the first one
    • Allows digestion time
    • Wait time should be calculated according to length of previous message
      • Maximum wait time of 8 seconds
  • Indicate wait time with a ‘typing bubble’
    • This gives the reader hard feedback that a response is coming, while also mimicking a real life chat experience
    • Note that on Facebook the typing indicators last maximum 20 seconds, so if a response will take longer, a loading message will need to be sent


  • Rely on user memory
    • Instructions shouldn’t have to be recalled, but rather should be visible or easily retrievable
    • This minimises the user’s cognitive load
  • Allow users to continue in an error loop for longer than 2 attempts
    • End loop with a prompt to go to help flow



  • Maintain context
    • Users should be able to change their mind without starting over entirely
    • Also very important when redirecting to a webpage/consultant
    • It is also good practice to let users know (if relevant) what context the bot has stored or which parameters are filled and which are missing
    • Be aware that in some cases, it may be unintuitive to keep context
  • Allows users to undo
    • Users should be able go one step back like they would on a webpage
    • When users go back a step, language shouldn’t be identical to previous bubbles
  • Have an escape hatch
    • Functionality is limited - user should easily be able to redirect to a consultant/additional help
  • Have shortcut/power move functionality
    • Experienced users shouldn’t have to go through entire flows each time
    • Shortcuts will also then need to be taught to users somehow
  • Integrate with existing business systems
    • Data storing, context retrieval, etc.
  • Favour linear navigation
    • (as opposed to nested navigation)
  • Favour structured input
  • Make it clear to users when a button is going to redirect them away from the bot
    • Unexpected redirects break user trust and will discourage them from exploring the bot


  • Flow through critical steps without asking for confirmation first
    • Confirm parameters
    • Error prevention
  • Rely on external help/documentation
    • Bot should be used without this
    • If needed, however, this information should be easy to search, focused, concise, and it should list concrete steps
  • Allow dead ends/white space
    • Each interaction should end with another option
    • Provide a way to reengage at the end of the interaction
    • [E.g. “say “hi” again if you need anything else”]
  • Show ALL options immediately/all the time
    • Better to keep branches simple instead of sub-sub-sub flows
    • Rather prompt to restart flow
  • Make it difficult for users to reset/go back to the main menu
    • This should be an easy option throughout



  • Be polite
    • Ps & Qs
  • Allow small talk functionality on your bot
    • Users are likely to play around
    • Adds to a positive UX
  • Assign a name and face to the bot
    • Shapes user perception
    • The most engaging profiles have faces
    • Humans will anthropomorphise any persona, even if they know it’s not real
    • Users also more likely to engage with a bot that has a face
    • A distinct persona will differentiate your bot
  • Use animation
    • Recommended to boost positive UX
    • Adds a dynamic
    • Can reinforce conversational style
    • Grabs attention
    • Encourages interactivity
  • Use emojis
    • Natural for a chat experience
    • Can also be used for a quick, streamlined feedback process
    • Not to be overused/used when inappropriate
  • Use humour
    • In moderation and where appropriate
    • Keep it safe and professional


  • Try to give user the impression they are talking to an actual human
    • This will fail and user trust will be broken
  • Assign gender
    • This is best avoided
    • Can draw too much attention to the bot character (as opposed to the content)
    • Can introduce bias
  • Use humour that will risk user trust
    • Don’t be like Hipmunk bot who said “Confirming credit card purchase for $712.85. Just kidding, I didn’t understand what you were saying.”
  • Place too much emphasis on the persona
    • “All sorted. Do you need anything else?” vs “I’ve ordered your flowers. Can I get anything else for you?”
  • Be overly formal

We hope you found this helpful! Here are some of the external sources we used to create our list of best practices if you’d like to read more: