体验设计师Alex Rice发在medium上的文章，原文地址

https://medium.com/@alexr790/designing-a-better-bot-part-2-thinking-tactically-59d4e543723a 

Designing a Better Bot, Part 2: Thinking Tactically

The way your bot behaves is just as important to the user experience as the reasons that it exists.

In myprevious article, I went over several conceptual and strategic designrecommendations to help you deliver a better experience with your bot.We’ll look at several more here, this time going into specific aspectsof the bot UX itself, as well as a few initial thoughts on the ethicsbehind bot design.

Aboveall, make sure you design a bot that offers something to the personinteracting with it, and be acutely aware of their needs and the journeythat you encounter them on. To that end, the UX recommendations herewill help ensure that your larger goals aren’t derailed by theconversation design itself.

It’s a conversation, not an app.

As convenient as it may seem to have the user say “menu” or “help” likethey’re yelling at a frozen macbook, you’re not really taking advantageof the fact that you’re having a conversation with a person. Aconversation follows particular paths and is bounded by a person’sability to retain and process information in that moment. Menus shouldbe used sparingly, if ever. Don’t just shoehorn an entire app or websiteinto your bot.

Furthermore,forcing someone to say things they wouldn’t normally use inconversation is antithetical to the entire concept of conversationalinterfaces. Don’t make the human speak robot just because your robotcan’t understand human.

Get to the point.

Thatsaid, “conversational interface” doesn’t mean “have a prolongedexchange with the user.” Sure, a bot with a well-defined personalitywill likely need to be able to speak outside of its main functionality,but you don’t need to overdo it. People aren’t coming to your bot totalk with it, they’re there to get something done. Conversationalinterfaces allow us to interact with technology and services in a waythat is fast, familiar, and driven by personality.

Use structured input.

When your bot says something without giving the user an idea of where togo next, it makes their experience unpleasantly confusing. To avoidthis unnecessary difficulty, use structured input to give options forwhat they can do with your bot.

Buttons and quick replies will take the burden of choice off of youruser and ease their cognitive load. Even though you’re essentiallyforcing them to say what you want them to, it keeps the user on thejourney that you’ve designed. In some cases, you can provide differentways of saying the same thing, to give them freedom to speak how theywant. No matter how smart your bot is, structured input will minimizefrustration and the chances of it breaking.

Use AI to expect the unexpected.

On that same note, whenever you don’t use structured input, you run therisk of the user breaking your bot. Unless you’re using a service thatcan help with AI, like Amazon Lex or api.ai, your bot’s “artificialintelligence” is going to be determined by your ability to think of allthe things a user could possibly say and all the ways they could say it.Every time your bot says “I don’t understand,” there’s a chance youruser will leave and never come back. Your bot doesn’t have to be dumberthan a bag of hammers if you don’t want it to be.

Be prepared for your bot to break.

Your bot will break, and there’s no way around that. It’s incredibly easily toderail conversations, but what you do in response will determine whetheror not the user sticks around.

Youneed to provide fallbacks that will alleviate and address frustration,such as default or context-sensitive messages that provide the user withnext steps. It must be absolutely impossible for the user to get into aprotracted back and forth loop of “I don’t understand” responses.

If having a fallback means having a human at the ready to take the reinsof the conversation, go for it. The last thing you want in a customerservice situation is your communication tool creating additional stress.

Onboard like you mean it.

Given that your bot might be the first one that someone interacts with,you have a responsibility to introduce the conventions and patterns ofthe medium to the user. Conversing with bots comes with rules andconsiderations that are specific to each interaction, despite the factthat it’s a conversation. This will change as the technology evolves,but right now, you need to ease the user into the bot’s capabilities,limitations, and the ways they can interact with it in a quick, tactful,and interactive way.

Testing makes better.

Test your bot repeatedly, like you would when designing any otherproduct or experience. Look for every possibly way to break your bot,and plan for every single thing the user could say or do. Put it infront of everyone. Don’t just test it with UX designers and botdevelopers, test it with your mom and dad, and anyone who’s lessfamiliar with technology than you. And most importantly, identify whoyour target user is, and test it with them.

You only get one shot at this.

If someone gets frustrated with your bot, or reaches a dead end, theywon’t say “oh, let me restart this and try again.” They’re going to walkaway and never come back.

Consider ethical context.

Last, and absolutely not least: you must always consider the designdecisions you make in an ethical context. You’re not designing somethingthat exists in a vacuum, but a product or experience that directlyaffects other people. I’m going to get into this in detail in a laterarticle, but for now, keep the following two pieces of advice in mind.

Don’t pretend to be human.

Don’t have your bot pretend to be a human. Be upfront about your bot’slimitations, and never try to trick your user into thinking it’s aperson. Even if it’s with the best of intentions to provide a pleasantcustomer experience, you’re setting yourself up to fail: If someone goesinto the experience expecting a level of conversation and competency that your bot can’t deliver, they’ll eventually figure it out. They’llrightly feel deceived and misled.

Be honest about data and privacy.

Tell the user who sees their data/input and if it’s going to livesomewhere permanent. For example, the fact that Amazon Echo records yourwords for anyone with device access to see and that Facebook messengerlogs all bot messages with the creator by default both surprises, as thetwo platforms aren’t upfront about either phenomena. Sure, we give up a sense of privacy when we put anything at all on the internet, but there are still plenty of things your audience might be sensitive or unhappy about you knowing.

(If you’d like to know more about the underlying ethics of AI and bot design, please be on the lookout for my upcoming article on the subject.)

At the end of the day, simply asking someone to interact with your bot is asking them to change their existing behavior. Just because someone spends all of their time in messenger, it doesn’t mean that they’re going to think to or want to do something else in it, like order a pizza or check on a UPS delivery. In every case so far, bots have been an additional, alternative way to do something, not a unique and irreplaceable one. A bot will not be your audience’s first choice of a way to do that thing, so you need to make sure they have a reason to use it beyond mere novelty.

Or, better yet, start with the goal of making a bot that offers an invaluable experience.