Tag: Useful

30 Jan

How To Create An Engaging And Useful Chatbot

by TBSCategories: News

Capital One. Adobe. Even Dominos has one. They’re chatbots, and they’re quickly becoming ubiquitous. A poor chatbot simply says “I’m sorry, I don’t understand” on repeat (or worse “error”.) A good chatbot feels almost-human, and helps answer questions so you don’t need to make a phone call or search the FAQ page.

But what makes a good chatbot experience? What are the table stakes that people expect from a chatbot, and what ruins that experience? In this article we’ll answer those questions and identify what you as a content designer can do to make your chatbot successful.

What Makes A Chatbot Unique?

A chatbot is a program that replicates human conversation. Most chatbots use decision trees to create a conversation. They either recognize key wuords and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Equally important to defining what a chatbot is, is identifying what it isn’t. Let’s dig into what a chatbot is — and clear up what it isn’t.

A Chatbot Is A Form Of Conversational Design

Chatbots replicate human conversations, and most chatbots use decision trees to do so. They either recognize key words and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Conversational design broadly refers to any conversation-like content, whether that comes through headers and text on a webpage, voice UI such as Google Home and Alexa, or chatbots. As such, chatbot content is one type of conversational design, but the two are not one-and-the-same. A chatbot is also not a human interacting through a chat interface (that is sometimes called “live chat”). It is specifically a computerized system.

Why does this matter? When design and engineering teams are determining the best way to communicate with their audiences, they are likely to use shorthand. I frequently hear designers say “then we [the company] will tell them [the audience] to confirm their password.” In this case, the designer may be referring to “telling” the audience via text on a page, or they may be implying a chatbot will appear to inform the audience. Early on in the concepting phase it may not matter what form of conversational design the team has in mind, but ultimately the content team will be responsible for significantly more work if the end result is a chatbot. With that in mind, it’s useful to clarify what form of conversational design the team has in mind.

One example of non-chatbot conversational design is a conversational UI. Oscar Insurance has a conversational UI, which they develop with a few best practices:

  • The headers are complete sentences.
  • Forms have help text with specific instructions (instead of examples).
  • Copy is written in the 2nd person, referring to the audience as “you”.

Voice UI can also “speak” to the audience, and if the team is considering that then they are either building a competitor to Alexa, Google Home, and Siri, or they are (more likely) building an app that these systems can download. Again, these may sound the same from a concepting perspective, but the requirements are vastly different. Voice UI has no visual design, and no ability to trigger or prompt the end-user into action. This is in stark contrast to a phone app, which may launch notifications without the end-user first opening the app.

A Chatbot Can Answer (Many) Questions

It may sound from this description as though chatbots are the perfect answer — they can launch notifications, they incorporate a visual UI, and they are conversational! Certainly, the popularity of chatbots is in part due to these benefits. But this can create an assumption that human conversation is the best way to connect with end-users. Sometimes that’s true — but not always!

In Michael J Metts’ Button talk “Sorry, I Can’t Help WIth That” he said a company must know what its goal is, and then determine if a chatbot will help fulfill that goal. This is a fantastic approach: a chatbot is a solution, and should be employed when it is the solution to a problem.

Customer service and sales are typically good goals for chatbots to fulfill. In both cases the problem may be “how might our customer service team respond quickly to common questions” or “how might our sales team help customers learn about a product or service in a quick and easy manner, without using significant employee time?” In these cases a chatbot can help people get the answers they want without needing to call and wait on hold.

However, if the problem is “how might our hospital more accurately diagnose health issues” or “how might our bank more quickly help employees find lost paychecks from their employers” a chatbot may not be appropriate. A human physician is much more accurate than a chatbot, and the end-users will pick up on that. Equally, a bank’s chatbot is unlikely to be able to connect to the numerous employers’ payroll systems required to track down paychecks. While the end-user might think they want answers from a chatbot, they’ll quickly lose trust when the chatbot can’t answer their questions.

In short, a chatbot is not a good way to handle nuances or extremely complicated situations, because of the numerous opportunities for human error. There are simply too many variables for “quick” and “accurate” to be accomplished in these situations.

A Chatbot Is Not An Algorithm

Never forget that a chatbot is only as good as its content. Yes, a chatbot is controlled by an algorithm, and can be bolstered by machine learning. But before machine learning can begin, the chatbot needs a set of rules, and needs content to speak. That’s the role of the content designer, UX writer, or content strategist to define.

We see this frequently in conversations around AI ethics. Voice assistants and chatbots are frequently identified as sexist and racially biased. They are not biased because the design and engineering team made a conscious choice to make them so. They are biased because they “reflect the biases in the viewpoints of the teams that built it,” to quote AI ethicist Josie Young in her TED talk.

For those of us building chatbots, this means we need to be consciously anti-sexist and anti-racist. We need to build chatbots thoughtfully, and not connect machine learning until after we have content designed that we want the AI to learn from. As with so many things, what a chatbot does is only half the story. It may “answer questions” — but what questions, and how? It may “direct people to their next steps” — but what are the appropriate next steps, and how does the chatbot respond when something goes wrong? In other words, what will make a true impact is how the chatbot accomplishes the things it does.

Best Practices For Engaging Chatbots

If your team is building a chatbot, hopefully you’ve already done a lot of the upfront work.

  • You’ve decided that a chatbot is the right solution.
  • You’ve identified the technological constraints, such as what system you’ll be using.
  • You’re looking into what capabilities will be available in that system, such as autocorrect or a built-in thesaurus of synonyms.

Now is when some executives say “plug it in and make it work!” and you must say “plug what in?!” As noted, your chatbot is not just an algorithm, and you have some content to design. It’s time to build the content for your chatbot. Let’s explore five best practices to make your chatbot humanesque:

  1. Define your actions.
  2. Separate your response types.
  3. Embrace your robot-self.
  4. Create a tone for each scenario.
  5. Design for errors.

1. Define Your Actions

Since a chatbot is not a magical solution to all things, you need to focus your work on specific user flows that people can accomplish with your chatbot. For example, let’s say you are building a chatbot for a company like FedEx or USPS, you may list out sample user flows like “track a package” and “update mailing address.” That means if an end-user asks the chatbot for help tracking a package, it may respond “what is the tracking number.” But the chabot should know its limitations. Perhaps one of the goals is “build trust.” Therefore if an end-user says “someone committed mail fraud in my name” the chatbot might express condolences and quickly transfer the end-user to a live customer service agent. Because the goal was to “build trust,” the team building the chatbot should recognize that anything involving sensitive information should be handled by a human — even if there is no technical or legal limitation.

There’s no one right way to go about this. Most organizations have some form of value propositions or design principles, which will help to identify the goal of the chatbot. There are also likely some requirements already defined. Therefore the goal can come from a cursory look at the requirements, and the requirements will become more specific after the goal is defined.

In an interview with Mike Bunner, VP, Director of Digital Marketing at Franklin Mint Federal Credit Union, Bunner said that without the chatbot, “our call center would be getting 3x the normal amount of calls.” Their goal could be assumed to be “decrease customer service hours.” This connects nicely to their chatbot’s initial prompt, which suggests “popular topics” that it can help with — likely these popular topics are the most common reasons people call the customer service team. In the same interview Bunner said the bot pulls its content directly from the member support content. Like many organizations, Franklin Mint had lots of helpful content, but had trouble getting people to view it.

2. Separate Your Response Types

When you think of a chatbot you likely think of one of two things:

  1. A chatbot that responds to anything an end-user types, picking up on what they want through key words and phrases.
  2. A chatbot that follows a series of decision trees, asking the end-user to select from a few options and then bringing them through a user flow.

Chatbots can do one or both of these, and it’s important to know what you’re aiming for. In fact, even if you intend to focus on decision trees, there’s the possibility of a user going off-script. With that in mind, consider how you want the chatbot to respond. If someone says “Help” or “Talk to a human” how will you route them?

As you think through the chatbot’s word associations, remember that words have context. When an end-user is editing their profile and they type in “phone number” they likely want to see where to edit their phone number. But if they’ve typed in something the chatbot doesn’t recognize, the chatbot said “I don’t understand” and then the end-user types in “phone number” they may be looking for a customer service line. This is an opportunity for engineering and content strategy to collaborate to create a well-designed and well-built bot.

This sort of thoughtful planning will come across in the end product. Adobe’s chatbot, for example, fails here. It begins by asking the end-user to freetype, but after getting a response the bot asks the end-user to select one of three options. As a user, I’m left wondering why I was asked to type if the bot couldn’t understand a simple keyword like “Adobe products”.

3. Embrace Your Robot-Self

Once you know what your chatbot can do, it’s time to think about how it will do it. First and foremost: don’t pretend that your chatbot is a human. In research with a former client, the client found that over 80% of people were comfortable interacting with a chatbot, and they liked when a chatbot had a name and personality. But those same people quickly lost faith in the bot and the organization when the chatbot pretended to be human.

One conversation with a client revolved around whether people would speak with a chatbot if they knew speaking to a human was an option. Testing found that yes, they would! In fact, reassuring end-users that a human being is available (as needed) actually increased the comfort they had in speaking to the chatbot.

The team at Hopelab had similar results when they built Vivibot, a chatbot for teens with cancer. Teens and young adults would often avoid confiding in their parents or health professionals. But Hopelab found that a chatbot removed some barriers. In their peer-reviewed randomized controlled study they were able to show that Vivibot not only provided valuable emotional support, but also improved anxiety.

Vivibot is an interesting chatbot example for several reasons. First, the bot is not intended for one-off solutions, but rather as an ongoing emotional support tool. This means the bot needed to have a variety of responses, so as to avoid sounding repetitive. Second, as a health-related bot, Vivibot needed to address sensitive subjects. She needed to be as transparent as possible, never defaulting to a generic “sounds good” for fear of alienating the people who rely on her when they don’t feel comfortable confiding in humans.

Imagine if Vivibot came across as insensitive? Emily Cummins, a writer with a piece on The Worst Chatbot Fails, shows an example where UX Magazine’s “UX Bear” asks “how would you describe the term bot to your grandma?” Emily responded “my grandma is dead,” and got back a thumbs up. This is a slightly confusing response from UX Bear, but would be potentially devastating from Vivibot.

In the near future we may see more states pass laws about bots pretending to be human, as California has. While it may seem unnecessary for the Chat Bears of the world, it’s clearly important for influential or sensitive topics, be they politics or healthcare.

4. Create A Tone For Each Scenario

When content strategists create a “voice and tone”, the two are different things. A voice is like a brand personality. It identifies how a company sounds, no matter what. The tone, however, will differ depending on the situation. The voice may be “friendly” but friendly sounds different in an error message than in a success message.

A chatbot should have a different voice from a company. It can say things like “oh no!” or “I’m happy for you.” when your company can’t. To that end, the first step of creating a chatbot voice is to develop a list of words your chatbot says. It’s important that a chatbot respond to the end-user, to let them know they’ve been heard. That means chatbots spend a lot of time saying things like “Got it” or “I understand” and you need to know what those agreement tokens sound like. Does your chatbot say “yes” or “yeah” or both? “Ok” or “okay”? “Great” or “I understand”? Parameters will help your chatbot sound consistent, such that the chatbot doesn’t respond “okie smokie” and then later “I appreciate your time,” but you’ll also need enough agreement tokens that your chatbot doesn’t sound overly robotic.

In Domino’s chatbot, the bot alternates agreement tokens like “great” and “got it”, but when it can’t understand the response it has no error token. The redundancy of the question “What city is that address in” (with no reference to the fact that it hadn’t understood my response) initially made me think the bot was broken.

5. Design For Errors

Chatbots, like other UIs, only have one chance to make a first impression. If the experience isn’t smooth and simple, people won’t return. With that in mind, a chatbot needs to have well written error messages. An error message from a chatbot may be as simple as saying “I don’t understand. Can you tell me again what you want?”, but it can also do far more.

For example, if your chatbot is an MVP, your error message may say something like “I can’t help you with that [feature] today, but ask me again in a few weeks.” Alternatively, if the end-user is asking for something the chatbot will never offer, suggest an alternative like “you can call customer service for help with that.”

Assuming you allow for free typing, there will also be the risk of someone typing a word or phrase your chatbot doesn’t understand. In that case, your chatbot may ask for clarification, or even say “I don’t understand”. But make sure you don’t leave your end-user in a loop! If the chatbot can’t understand after two or three tries, offer to put the end-user in touch with a human.

That said, error planning goes far beyond a simple “I don’t understand” or “I can’t help with that”. A well-built chatbot considers how end-users view the tasks they want to complete. Take for example a payroll system, which might use a chatbot to help employees check on their upcoming paychecks, tax deductions, and other requested pre-tax deductions. In a system like this, the chatbot is likely able to answer questions such as:

  • When is my next paycheck scheduled to be sent to me?
  • I want to set up direct deposit.
  • When can I change my 401k deductions?

It’s possible the payroll system is connected to some of the employee’s benefits — for example, it may have a flow built to allow the employee to change deductions. But the payroll chatbot team should be aware that employees may come to them with related questions and issues, such as:

  • What benefits do I have available if I go on sick leave?
  • I need to change my 401k allocations.
  • I didn’t receive my last paycheck.

It’s unlikely that the payroll system is also the benefits system. But the chatbot team needs to know that employees don’t think in terms of capabilities. They think in terms of needs. “I need to take care of my 401k” may mean going to one system to set up the deductions, and another system to change the allocations. If the chatbot says nothing but “I can’t help with that” in response, then the chatbot has failed. Our hypothetical payroll system could instead build goodwill by explaining the system to a member and recommending they speak to their HR representative.

Webflow’s Customer Support chatbot does an excellent job of not only defining what it can do, but telling the user upfront: “[I]f I’m unable to solve a problem for you, a member of our Support team will get back to you by email. Note: We don’t provide support by phone or live chat at the moment, as we’ve found it most impactful to help you via email.” You may not think of this as an error message, because it’s really about solving the problem before it ever becomes an error.

Internally, this means the team should define user flows from the end-user’s perspective, not just from the technical standpoint of what is possible. If Webflow had only considered things from their own perspective, they wouldn’t have thought to clarify what they don’t do. They would merely have solved the problems they could, and potentially left users wondering why (for example) they couldn’t find a phone number to call.

Bringing Humanity To Your Chatbot

Of course a chatbot is not a person. But it’s also not a second-choice option to a person. A chatbot can help people easily get answers to their questions, it can help them connect when they’re feeling vulnerable, and it can simplify complex processes. It is, like so many tools, a perfect solution to many potential problems.

As the creators of these chatbots, that means we have an important mission! We must create appropriate responses, humanesque tones, and helpful user flows. We must write content to respond to people in different moods, and with diverse needs — anticipating their next steps and guiding them appropriately. Most of all, we must create transparent and trustworthy bots, so that the people interacting with them can trust the information they provide.

Just remember: Define your actions, so that your chatbot accomplishes a business goal and a user need. Build out a script for your chatbot and decide if your chatbot will respond to off-script requests. Embrace your robot self and never pretend to be a human. Create a tone for each scenario. And lastly, make sure your chatbot can handle errors smoothly.

Your chatbot is a program, not a human. Still, a well-designed program can bring happiness and ease to your audience! With these five steps,your chatbot will be capable of a near-human connection with your end-user. Now it’s your turn: follow these best practices and let us know how your audience responds to your bot.

Articles on Smashing Magazine — For Web Designers And Developers

30 Jan

How To Create An Engaging And Useful Chatbot

by TBSCategories: News

Capital One. Adobe. Even Dominos has one. They’re chatbots, and they’re quickly becoming ubiquitous. A poor chatbot simply says “I’m sorry, I don’t understand” on repeat (or worse “error”.) A good chatbot feels almost-human, and helps answer questions so you don’t need to make a phone call or search the FAQ page.

But what makes a good chatbot experience? What are the table stakes that people expect from a chatbot, and what ruins that experience? In this article we’ll answer those questions and identify what you as a content designer can do to make your chatbot successful.

What Makes A Chatbot Unique?

A chatbot is a program that replicates human conversation. Most chatbots use decision trees to create a conversation. They either recognize key wuords and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Equally important to defining what a chatbot is, is identifying what it isn’t. Let’s dig into what a chatbot is — and clear up what it isn’t.

A Chatbot Is A Form Of Conversational Design

Chatbots replicate human conversations, and most chatbots use decision trees to do so. They either recognize key words and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Conversational design broadly refers to any conversation-like content, whether that comes through headers and text on a webpage, voice UI such as Google Home and Alexa, or chatbots. As such, chatbot content is one type of conversational design, but the two are not one-and-the-same. A chatbot is also not a human interacting through a chat interface (that is sometimes called “live chat”). It is specifically a computerized system.

Why does this matter? When design and engineering teams are determining the best way to communicate with their audiences, they are likely to use shorthand. I frequently hear designers say “then we [the company] will tell them [the audience] to confirm their password.” In this case, the designer may be referring to “telling” the audience via text on a page, or they may be implying a chatbot will appear to inform the audience. Early on in the concepting phase it may not matter what form of conversational design the team has in mind, but ultimately the content team will be responsible for significantly more work if the end result is a chatbot. With that in mind, it’s useful to clarify what form of conversational design the team has in mind.

One example of non-chatbot conversational design is a conversational UI. Oscar Insurance has a conversational UI, which they develop with a few best practices:

  • The headers are complete sentences.
  • Forms have help text with specific instructions (instead of examples).
  • Copy is written in the 2nd person, referring to the audience as “you”.

Voice UI can also “speak” to the audience, and if the team is considering that then they are either building a competitor to Alexa, Google Home, and Siri, or they are (more likely) building an app that these systems can download. Again, these may sound the same from a concepting perspective, but the requirements are vastly different. Voice UI has no visual design, and no ability to trigger or prompt the end-user into action. This is in stark contrast to a phone app, which may launch notifications without the end-user first opening the app.

A Chatbot Can Answer (Many) Questions

It may sound from this description as though chatbots are the perfect answer — they can launch notifications, they incorporate a visual UI, and they are conversational! Certainly, the popularity of chatbots is in part due to these benefits. But this can create an assumption that human conversation is the best way to connect with end-users. Sometimes that’s true — but not always!

In Michael J Metts’ Button talk “Sorry, I Can’t Help WIth That” he said a company must know what its goal is, and then determine if a chatbot will help fulfill that goal. This is a fantastic approach: a chatbot is a solution, and should be employed when it is the solution to a problem.

Customer service and sales are typically good goals for chatbots to fulfill. In both cases the problem may be “how might our customer service team respond quickly to common questions” or “how might our sales team help customers learn about a product or service in a quick and easy manner, without using significant employee time?” In these cases a chatbot can help people get the answers they want without needing to call and wait on hold.

However, if the problem is “how might our hospital more accurately diagnose health issues” or “how might our bank more quickly help employees find lost paychecks from their employers” a chatbot may not be appropriate. A human physician is much more accurate than a chatbot, and the end-users will pick up on that. Equally, a bank’s chatbot is unlikely to be able to connect to the numerous employers’ payroll systems required to track down paychecks. While the end-user might think they want answers from a chatbot, they’ll quickly lose trust when the chatbot can’t answer their questions.

In short, a chatbot is not a good way to handle nuances or extremely complicated situations, because of the numerous opportunities for human error. There are simply too many variables for “quick” and “accurate” to be accomplished in these situations.

A Chatbot Is Not An Algorithm

Never forget that a chatbot is only as good as its content. Yes, a chatbot is controlled by an algorithm, and can be bolstered by machine learning. But before machine learning can begin, the chatbot needs a set of rules, and needs content to speak. That’s the role of the content designer, UX writer, or content strategist to define.

We see this frequently in conversations around AI ethics. Voice assistants and chatbots are frequently identified as sexist and racially biased. They are not biased because the design and engineering team made a conscious choice to make them so. They are biased because they “reflect the biases in the viewpoints of the teams that built it,” to quote AI ethicist Josie Young in her TED talk.

For those of us building chatbots, this means we need to be consciously anti-sexist and anti-racist. We need to build chatbots thoughtfully, and not connect machine learning until after we have content designed that we want the AI to learn from. As with so many things, what a chatbot does is only half the story. It may “answer questions” — but what questions, and how? It may “direct people to their next steps” — but what are the appropriate next steps, and how does the chatbot respond when something goes wrong? In other words, what will make a true impact is how the chatbot accomplishes the things it does.

Best Practices For Engaging Chatbots

If your team is building a chatbot, hopefully you’ve already done a lot of the upfront work.

  • You’ve decided that a chatbot is the right solution.
  • You’ve identified the technological constraints, such as what system you’ll be using.
  • You’re looking into what capabilities will be available in that system, such as autocorrect or a built-in thesaurus of synonyms.

Now is when some executives say “plug it in and make it work!” and you must say “plug what in?!” As noted, your chatbot is not just an algorithm, and you have some content to design. It’s time to build the content for your chatbot. Let’s explore five best practices to make your chatbot humanesque:

  1. Define your actions.
  2. Separate your response types.
  3. Embrace your robot-self.
  4. Create a tone for each scenario.
  5. Design for errors.

1. Define Your Actions

Since a chatbot is not a magical solution to all things, you need to focus your work on specific user flows that people can accomplish with your chatbot. For example, let’s say you are building a chatbot for a company like FedEx or USPS, you may list out sample user flows like “track a package” and “update mailing address.” That means if an end-user asks the chatbot for help tracking a package, it may respond “what is the tracking number.” But the chabot should know its limitations. Perhaps one of the goals is “build trust.” Therefore if an end-user says “someone committed mail fraud in my name” the chatbot might express condolences and quickly transfer the end-user to a live customer service agent. Because the goal was to “build trust,” the team building the chatbot should recognize that anything involving sensitive information should be handled by a human — even if there is no technical or legal limitation.

There’s no one right way to go about this. Most organizations have some form of value propositions or design principles, which will help to identify the goal of the chatbot. There are also likely some requirements already defined. Therefore the goal can come from a cursory look at the requirements, and the requirements will become more specific after the goal is defined.

In an interview with Mike Bunner, VP, Director of Digital Marketing at Franklin Mint Federal Credit Union, Bunner said that without the chatbot, “our call center would be getting 3x the normal amount of calls.” Their goal could be assumed to be “decrease customer service hours.” This connects nicely to their chatbot’s initial prompt, which suggests “popular topics” that it can help with — likely these popular topics are the most common reasons people call the customer service team. In the same interview Bunner said the bot pulls its content directly from the member support content. Like many organizations, Franklin Mint had lots of helpful content, but had trouble getting people to view it.

2. Separate Your Response Types

When you think of a chatbot you likely think of one of two things:

  1. A chatbot that responds to anything an end-user types, picking up on what they want through key words and phrases.
  2. A chatbot that follows a series of decision trees, asking the end-user to select from a few options and then bringing them through a user flow.

Chatbots can do one or both of these, and it’s important to know what you’re aiming for. In fact, even if you intend to focus on decision trees, there’s the possibility of a user going off-script. With that in mind, consider how you want the chatbot to respond. If someone says “Help” or “Talk to a human” how will you route them?

As you think through the chatbot’s word associations, remember that words have context. When an end-user is editing their profile and they type in “phone number” they likely want to see where to edit their phone number. But if they’ve typed in something the chatbot doesn’t recognize, the chatbot said “I don’t understand” and then the end-user types in “phone number” they may be looking for a customer service line. This is an opportunity for engineering and content strategy to collaborate to create a well-designed and well-built bot.

This sort of thoughtful planning will come across in the end product. Adobe’s chatbot, for example, fails here. It begins by asking the end-user to freetype, but after getting a response the bot asks the end-user to select one of three options. As a user, I’m left wondering why I was asked to type if the bot couldn’t understand a simple keyword like “Adobe products”.

3. Embrace Your Robot-Self

Once you know what your chatbot can do, it’s time to think about how it will do it. First and foremost: don’t pretend that your chatbot is a human. In research with a former client, the client found that over 80% of people were comfortable interacting with a chatbot, and they liked when a chatbot had a name and personality. But those same people quickly lost faith in the bot and the organization when the chatbot pretended to be human.

One conversation with a client revolved around whether people would speak with a chatbot if they knew speaking to a human was an option. Testing found that yes, they would! In fact, reassuring end-users that a human being is available (as needed) actually increased the comfort they had in speaking to the chatbot.

The team at Hopelab had similar results when they built Vivibot, a chatbot for teens with cancer. Teens and young adults would often avoid confiding in their parents or health professionals. But Hopelab found that a chatbot removed some barriers. In their peer-reviewed randomized controlled study they were able to show that Vivibot not only provided valuable emotional support, but also improved anxiety.

Vivibot is an interesting chatbot example for several reasons. First, the bot is not intended for one-off solutions, but rather as an ongoing emotional support tool. This means the bot needed to have a variety of responses, so as to avoid sounding repetitive. Second, as a health-related bot, Vivibot needed to address sensitive subjects. She needed to be as transparent as possible, never defaulting to a generic “sounds good” for fear of alienating the people who rely on her when they don’t feel comfortable confiding in humans.

Imagine if Vivibot came across as insensitive? Emily Cummins, a writer with a piece on The Worst Chatbot Fails, shows an example where UX Magazine’s “UX Bear” asks “how would you describe the term bot to your grandma?” Emily responded “my grandma is dead,” and got back a thumbs up. This is a slightly confusing response from UX Bear, but would be potentially devastating from Vivibot.

In the near future we may see more states pass laws about bots pretending to be human, as California has. While it may seem unnecessary for the Chat Bears of the world, it’s clearly important for influential or sensitive topics, be they politics or healthcare.

4. Create A Tone For Each Scenario

When content strategists create a “voice and tone”, the two are different things. A voice is like a brand personality. It identifies how a company sounds, no matter what. The tone, however, will differ depending on the situation. The voice may be “friendly” but friendly sounds different in an error message than in a success message.

A chatbot should have a different voice from a company. It can say things like “oh no!” or “I’m happy for you.” when your company can’t. To that end, the first step of creating a chatbot voice is to develop a list of words your chatbot says. It’s important that a chatbot respond to the end-user, to let them know they’ve been heard. That means chatbots spend a lot of time saying things like “Got it” or “I understand” and you need to know what those agreement tokens sound like. Does your chatbot say “yes” or “yeah” or both? “Ok” or “okay”? “Great” or “I understand”? Parameters will help your chatbot sound consistent, such that the chatbot doesn’t respond “okie smokie” and then later “I appreciate your time,” but you’ll also need enough agreement tokens that your chatbot doesn’t sound overly robotic.

In Domino’s chatbot, the bot alternates agreement tokens like “great” and “got it”, but when it can’t understand the response it has no error token. The redundancy of the question “What city is that address in” (with no reference to the fact that it hadn’t understood my response) initially made me think the bot was broken.

5. Design For Errors

Chatbots, like other UIs, only have one chance to make a first impression. If the experience isn’t smooth and simple, people won’t return. With that in mind, a chatbot needs to have well written error messages. An error message from a chatbot may be as simple as saying “I don’t understand. Can you tell me again what you want?”, but it can also do far more.

For example, if your chatbot is an MVP, your error message may say something like “I can’t help you with that [feature] today, but ask me again in a few weeks.” Alternatively, if the end-user is asking for something the chatbot will never offer, suggest an alternative like “you can call customer service for help with that.”

Assuming you allow for free typing, there will also be the risk of someone typing a word or phrase your chatbot doesn’t understand. In that case, your chatbot may ask for clarification, or even say “I don’t understand”. But make sure you don’t leave your end-user in a loop! If the chatbot can’t understand after two or three tries, offer to put the end-user in touch with a human.

That said, error planning goes far beyond a simple “I don’t understand” or “I can’t help with that”. A well-built chatbot considers how end-users view the tasks they want to complete. Take for example a payroll system, which might use a chatbot to help employees check on their upcoming paychecks, tax deductions, and other requested pre-tax deductions. In a system like this, the chatbot is likely able to answer questions such as:

  • When is my next paycheck scheduled to be sent to me?
  • I want to set up direct deposit.
  • When can I change my 401k deductions?

It’s possible the payroll system is connected to some of the employee’s benefits — for example, it may have a flow built to allow the employee to change deductions. But the payroll chatbot team should be aware that employees may come to them with related questions and issues, such as:

  • What benefits do I have available if I go on sick leave?
  • I need to change my 401k allocations.
  • I didn’t receive my last paycheck.

It’s unlikely that the payroll system is also the benefits system. But the chatbot team needs to know that employees don’t think in terms of capabilities. They think in terms of needs. “I need to take care of my 401k” may mean going to one system to set up the deductions, and another system to change the allocations. If the chatbot says nothing but “I can’t help with that” in response, then the chatbot has failed. Our hypothetical payroll system could instead build goodwill by explaining the system to a member and recommending they speak to their HR representative.

Webflow’s Customer Support chatbot does an excellent job of not only defining what it can do, but telling the user upfront: “[I]f I’m unable to solve a problem for you, a member of our Support team will get back to you by email. Note: We don’t provide support by phone or live chat at the moment, as we’ve found it most impactful to help you via email.” You may not think of this as an error message, because it’s really about solving the problem before it ever becomes an error.

Internally, this means the team should define user flows from the end-user’s perspective, not just from the technical standpoint of what is possible. If Webflow had only considered things from their own perspective, they wouldn’t have thought to clarify what they don’t do. They would merely have solved the problems they could, and potentially left users wondering why (for example) they couldn’t find a phone number to call.

Bringing Humanity To Your Chatbot

Of course a chatbot is not a person. But it’s also not a second-choice option to a person. A chatbot can help people easily get answers to their questions, it can help them connect when they’re feeling vulnerable, and it can simplify complex processes. It is, like so many tools, a perfect solution to many potential problems.

As the creators of these chatbots, that means we have an important mission! We must create appropriate responses, humanesque tones, and helpful user flows. We must write content to respond to people in different moods, and with diverse needs — anticipating their next steps and guiding them appropriately. Most of all, we must create transparent and trustworthy bots, so that the people interacting with them can trust the information they provide.

Just remember: Define your actions, so that your chatbot accomplishes a business goal and a user need. Build out a script for your chatbot and decide if your chatbot will respond to off-script requests. Embrace your robot self and never pretend to be a human. Create a tone for each scenario. And lastly, make sure your chatbot can handle errors smoothly.

Your chatbot is a program, not a human. Still, a well-designed program can bring happiness and ease to your audience! With these five steps,your chatbot will be capable of a near-human connection with your end-user. Now it’s your turn: follow these best practices and let us know how your audience responds to your bot.

Articles on Smashing Magazine — For Web Designers And Developers

29 Jan

How To Create An Engaging And Useful Chatbot

by TBSCategories: News

Capital One. Adobe. Even Dominos has one. They’re chatbots, and they’re quickly becoming ubiquitous. A poor chatbot simply says “I’m sorry, I don’t understand” on repeat (or worse “error”.) A good chatbot feels almost-human, and helps answer questions so you don’t need to make a phone call or search the FAQ page.

But what makes a good chatbot experience? What are the table stakes that people expect from a chatbot, and what ruins that experience? In this article we’ll answer those questions and identify what you as a content designer can do to make your chatbot successful.

What Makes A Chatbot Unique?

A chatbot is a program that replicates human conversation. Most chatbots use decision trees to create a conversation. They either recognize key wuords and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Equally important to defining what a chatbot is, is identifying what it isn’t. Let’s dig into what a chatbot is — and clear up what it isn’t.

A Chatbot Is A Form Of Conversational Design

Chatbots replicate human conversations, and most chatbots use decision trees to do so. They either recognize key words and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Conversational design broadly refers to any conversation-like content, whether that comes through headers and text on a webpage, voice UI such as Google Home and Alexa, or chatbots. As such, chatbot content is one type of conversational design, but the two are not one-and-the-same. A chatbot is also not a human interacting through a chat interface (that is sometimes called “live chat”). It is specifically a computerized system.

Why does this matter? When design and engineering teams are determining the best way to communicate with their audiences, they are likely to use shorthand. I frequently hear designers say “then we [the company] will tell them [the audience] to confirm their password.” In this case, the designer may be referring to “telling” the audience via text on a page, or they may be implying a chatbot will appear to inform the audience. Early on in the concepting phase it may not matter what form of conversational design the team has in mind, but ultimately the content team will be responsible for significantly more work if the end result is a chatbot. With that in mind, it’s useful to clarify what form of conversational design the team has in mind.

One example of non-chatbot conversational design is a conversational UI. Oscar Insurance has a conversational UI, which they develop with a few best practices:

  • The headers are complete sentences.
  • Forms have help text with specific instructions (instead of examples).
  • Copy is written in the 2nd person, referring to the audience as “you”.

Voice UI can also “speak” to the audience, and if the team is considering that then they are either building a competitor to Alexa, Google Home, and Siri, or they are (more likely) building an app that these systems can download. Again, these may sound the same from a concepting perspective, but the requirements are vastly different. Voice UI has no visual design, and no ability to trigger or prompt the end-user into action. This is in stark contrast to a phone app, which may launch notifications without the end-user first opening the app.

A Chatbot Can Answer (Many) Questions

It may sound from this description as though chatbots are the perfect answer — they can launch notifications, they incorporate a visual UI, and they are conversational! Certainly, the popularity of chatbots is in part due to these benefits. But this can create an assumption that human conversation is the best way to connect with end-users. Sometimes that’s true — but not always!

In Michael J Metts’ Button talk “Sorry, I Can’t Help WIth That” he said a company must know what its goal is, and then determine if a chatbot will help fulfill that goal. This is a fantastic approach: a chatbot is a solution, and should be employed when it is the solution to a problem.

Customer service and sales are typically good goals for chatbots to fulfill. In both cases the problem may be “how might our customer service team respond quickly to common questions” or “how might our sales team help customers learn about a product or service in a quick and easy manner, without using significant employee time?” In these cases a chatbot can help people get the answers they want without needing to call and wait on hold.

However, if the problem is “how might our hospital more accurately diagnose health issues” or “how might our bank more quickly help employees find lost paychecks from their employers” a chatbot may not be appropriate. A human physician is much more accurate than a chatbot, and the end-users will pick up on that. Equally, a bank’s chatbot is unlikely to be able to connect to the numerous employers’ payroll systems required to track down paychecks. While the end-user might think they want answers from a chatbot, they’ll quickly lose trust when the chatbot can’t answer their questions.

In short, a chatbot is not a good way to handle nuances or extremely complicated situations, because of the numerous opportunities for human error. There are simply too many variables for “quick” and “accurate” to be accomplished in these situations.

A Chatbot Is Not An Algorithm

Never forget that a chatbot is only as good as its content. Yes, a chatbot is controlled by an algorithm, and can be bolstered by machine learning. But before machine learning can begin, the chatbot needs a set of rules, and needs content to speak. That’s the role of the content designer, UX writer, or content strategist to define.

We see this frequently in conversations around AI ethics. Voice assistants and chatbots are frequently identified as sexist and racially biased. They are not biased because the design and engineering team made a conscious choice to make them so. They are biased because they “reflect the biases in the viewpoints of the teams that built it,” to quote AI ethicist Josie Young in her TED talk.

For those of us building chatbots, this means we need to be consciously anti-sexist and anti-racist. We need to build chatbots thoughtfully, and not connect machine learning until after we have content designed that we want the AI to learn from. As with so many things, what a chatbot does is only half the story. It may “answer questions” — but what questions, and how? It may “direct people to their next steps” — but what are the appropriate next steps, and how does the chatbot respond when something goes wrong? In other words, what will make a true impact is how the chatbot accomplishes the things it does.

Best Practices For Engaging Chatbots

If your team is building a chatbot, hopefully you’ve already done a lot of the upfront work.

  • You’ve decided that a chatbot is the right solution.
  • You’ve identified the technological constraints, such as what system you’ll be using.
  • You’re looking into what capabilities will be available in that system, such as autocorrect or a built-in thesaurus of synonyms.

Now is when some executives say “plug it in and make it work!” and you must say “plug what in?!” As noted, your chatbot is not just an algorithm, and you have some content to design. It’s time to build the content for your chatbot. Let’s explore five best practices to make your chatbot humanesque:

  1. Define your actions.
  2. Separate your response types.
  3. Embrace your robot-self.
  4. Create a tone for each scenario.
  5. Design for errors.

1. Define Your Actions

Since a chatbot is not a magical solution to all things, you need to focus your work on specific user flows that people can accomplish with your chatbot. For example, let’s say you are building a chatbot for a company like FedEx or USPS, you may list out sample user flows like “track a package” and “update mailing address.” That means if an end-user asks the chatbot for help tracking a package, it may respond “what is the tracking number.” But the chabot should know its limitations. Perhaps one of the goals is “build trust.” Therefore if an end-user says “someone committed mail fraud in my name” the chatbot might express condolences and quickly transfer the end-user to a live customer service agent. Because the goal was to “build trust,” the team building the chatbot should recognize that anything involving sensitive information should be handled by a human — even if there is no technical or legal limitation.

There’s no one right way to go about this. Most organizations have some form of value propositions or design principles, which will help to identify the goal of the chatbot. There are also likely some requirements already defined. Therefore the goal can come from a cursory look at the requirements, and the requirements will become more specific after the goal is defined.

In an interview with Mike Bunner, VP, Director of Digital Marketing at Franklin Mint Federal Credit Union, Bunner said that without the chatbot, “our call center would be getting 3x the normal amount of calls.” Their goal could be assumed to be “decrease customer service hours.” This connects nicely to their chatbot’s initial prompt, which suggests “popular topics” that it can help with — likely these popular topics are the most common reasons people call the customer service team. In the same interview Bunner said the bot pulls its content directly from the member support content. Like many organizations, Franklin Mint had lots of helpful content, but had trouble getting people to view it.

2. Separate Your Response Types

When you think of a chatbot you likely think of one of two things:

  1. A chatbot that responds to anything an end-user types, picking up on what they want through key words and phrases.
  2. A chatbot that follows a series of decision trees, asking the end-user to select from a few options and then bringing them through a user flow.

Chatbots can do one or both of these, and it’s important to know what you’re aiming for. In fact, even if you intend to focus on decision trees, there’s the possibility of a user going off-script. With that in mind, consider how you want the chatbot to respond. If someone says “Help” or “Talk to a human” how will you route them?

As you think through the chatbot’s word associations, remember that words have context. When an end-user is editing their profile and they type in “phone number” they likely want to see where to edit their phone number. But if they’ve typed in something the chatbot doesn’t recognize, the chatbot said “I don’t understand” and then the end-user types in “phone number” they may be looking for a customer service line. This is an opportunity for engineering and content strategy to collaborate to create a well-designed and well-built bot.

This sort of thoughtful planning will come across in the end product. Adobe’s chatbot, for example, fails here. It begins by asking the end-user to freetype, but after getting a response the bot asks the end-user to select one of three options. As a user, I’m left wondering why I was asked to type if the bot couldn’t understand a simple keyword like “Adobe products”.

3. Embrace Your Robot-Self

Once you know what your chatbot can do, it’s time to think about how it will do it. First and foremost: don’t pretend that your chatbot is a human. In research with a former client, the client found that over 80% of people were comfortable interacting with a chatbot, and they liked when a chatbot had a name and personality. But those same people quickly lost faith in the bot and the organization when the chatbot pretended to be human.

One conversation with a client revolved around whether people would speak with a chatbot if they knew speaking to a human was an option. Testing found that yes, they would! In fact, reassuring end-users that a human being is available (as needed) actually increased the comfort they had in speaking to the chatbot.

The team at Hopelab had similar results when they built Vivibot, a chatbot for teens with cancer. Teens and young adults would often avoid confiding in their parents or health professionals. But Hopelab found that a chatbot removed some barriers. In their peer-reviewed randomized controlled study they were able to show that Vivibot not only provided valuable emotional support, but also improved anxiety.

Vivibot is an interesting chatbot example for several reasons. First, the bot is not intended for one-off solutions, but rather as an ongoing emotional support tool. This means the bot needed to have a variety of responses, so as to avoid sounding repetitive. Second, as a health-related bot, Vivibot needed to address sensitive subjects. She needed to be as transparent as possible, never defaulting to a generic “sounds good” for fear of alienating the people who rely on her when they don’t feel comfortable confiding in humans.

Imagine if Vivibot came across as insensitive? Emily Cummins, a writer with a piece on The Worst Chatbot Fails, shows an example where UX Magazine’s “UX Bear” asks “how would you describe the term bot to your grandma?” Emily responded “my grandma is dead,” and got back a thumbs up. This is a slightly confusing response from UX Bear, but would be potentially devastating from Vivibot.

In the near future we may see more states pass laws about bots pretending to be human, as California has. While it may seem unnecessary for the Chat Bears of the world, it’s clearly important for influential or sensitive topics, be they politics or healthcare.

4. Create A Tone For Each Scenario

When content strategists create a “voice and tone”, the two are different things. A voice is like a brand personality. It identifies how a company sounds, no matter what. The tone, however, will differ depending on the situation. The voice may be “friendly” but friendly sounds different in an error message than in a success message.

A chatbot should have a different voice from a company. It can say things like “oh no!” or “I’m happy for you.” when your company can’t. To that end, the first step of creating a chatbot voice is to develop a list of words your chatbot says. It’s important that a chatbot respond to the end-user, to let them know they’ve been heard. That means chatbots spend a lot of time saying things like “Got it” or “I understand” and you need to know what those agreement tokens sound like. Does your chatbot say “yes” or “yeah” or both? “Ok” or “okay”? “Great” or “I understand”? Parameters will help your chatbot sound consistent, such that the chatbot doesn’t respond “okie smokie” and then later “I appreciate your time,” but you’ll also need enough agreement tokens that your chatbot doesn’t sound overly robotic.

In Domino’s chatbot, the bot alternates agreement tokens like “great” and “got it”, but when it can’t understand the response it has no error token. The redundancy of the question “What city is that address in” (with no reference to the fact that it hadn’t understood my response) initially made me think the bot was broken.

5. Design For Errors

Chatbots, like other UIs, only have one chance to make a first impression. If the experience isn’t smooth and simple, people won’t return. With that in mind, a chatbot needs to have well written error messages. An error message from a chatbot may be as simple as saying “I don’t understand. Can you tell me again what you want?”, but it can also do far more.

For example, if your chatbot is an MVP, your error message may say something like “I can’t help you with that [feature] today, but ask me again in a few weeks.” Alternatively, if the end-user is asking for something the chatbot will never offer, suggest an alternative like “you can call customer service for help with that.”

Assuming you allow for free typing, there will also be the risk of someone typing a word or phrase your chatbot doesn’t understand. In that case, your chatbot may ask for clarification, or even say “I don’t understand”. But make sure you don’t leave your end-user in a loop! If the chatbot can’t understand after two or three tries, offer to put the end-user in touch with a human.

That said, error planning goes far beyond a simple “I don’t understand” or “I can’t help with that”. A well-built chatbot considers how end-users view the tasks they want to complete. Take for example a payroll system, which might use a chatbot to help employees check on their upcoming paychecks, tax deductions, and other requested pre-tax deductions. In a system like this, the chatbot is likely able to answer questions such as:

  • When is my next paycheck scheduled to be sent to me?
  • I want to set up direct deposit.
  • When can I change my 401k deductions?

It’s possible the payroll system is connected to some of the employee’s benefits — for example, it may have a flow built to allow the employee to change deductions. But the payroll chatbot team should be aware that employees may come to them with related questions and issues, such as:

  • What benefits do I have available if I go on sick leave?
  • I need to change my 401k allocations.
  • I didn’t receive my last paycheck.

It’s unlikely that the payroll system is also the benefits system. But the chatbot team needs to know that employees don’t think in terms of capabilities. They think in terms of needs. “I need to take care of my 401k” may mean going to one system to set up the deductions, and another system to change the allocations. If the chatbot says nothing but “I can’t help with that” in response, then the chatbot has failed. Our hypothetical payroll system could instead build goodwill by explaining the system to a member and recommending they speak to their HR representative.

Webflow’s Customer Support chatbot does an excellent job of not only defining what it can do, but telling the user upfront: “[I]f I’m unable to solve a problem for you, a member of our Support team will get back to you by email. Note: We don’t provide support by phone or live chat at the moment, as we’ve found it most impactful to help you via email.” You may not think of this as an error message, because it’s really about solving the problem before it ever becomes an error.

Internally, this means the team should define user flows from the end-user’s perspective, not just from the technical standpoint of what is possible. If Webflow had only considered things from their own perspective, they wouldn’t have thought to clarify what they don’t do. They would merely have solved the problems they could, and potentially left users wondering why (for example) they couldn’t find a phone number to call.

Bringing Humanity To Your Chatbot

Of course a chatbot is not a person. But it’s also not a second-choice option to a person. A chatbot can help people easily get answers to their questions, it can help them connect when they’re feeling vulnerable, and it can simplify complex processes. It is, like so many tools, a perfect solution to many potential problems.

As the creators of these chatbots, that means we have an important mission! We must create appropriate responses, humanesque tones, and helpful user flows. We must write content to respond to people in different moods, and with diverse needs — anticipating their next steps and guiding them appropriately. Most of all, we must create transparent and trustworthy bots, so that the people interacting with them can trust the information they provide.

Just remember: Define your actions, so that your chatbot accomplishes a business goal and a user need. Build out a script for your chatbot and decide if your chatbot will respond to off-script requests. Embrace your robot self and never pretend to be a human. Create a tone for each scenario. And lastly, make sure your chatbot can handle errors smoothly.

Your chatbot is a program, not a human. Still, a well-designed program can bring happiness and ease to your audience! With these five steps,your chatbot will be capable of a near-human connection with your end-user. Now it’s your turn: follow these best practices and let us know how your audience responds to your bot.

Articles on Smashing Magazine — For Web Designers And Developers

29 Jan

How To Create An Engaging And Useful Chatbot

by TBSCategories: News

Capital One. Adobe. Even Dominos has one. They’re chatbots, and they’re quickly becoming ubiquitous. A poor chatbot simply says “I’m sorry, I don’t understand” on repeat (or worse “error”.) A good chatbot feels almost-human, and helps answer questions so you don’t need to make a phone call or search the FAQ page.

But what makes a good chatbot experience? What are the table stakes that people expect from a chatbot, and what ruins that experience? In this article we’ll answer those questions and identify what you as a content designer can do to make your chatbot successful.

What Makes A Chatbot Unique?

A chatbot is a program that replicates human conversation. Most chatbots use decision trees to create a conversation. They either recognize key wuords and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Equally important to defining what a chatbot is, is identifying what it isn’t. Let’s dig into what a chatbot is — and clear up what it isn’t.

A Chatbot Is A Form Of Conversational Design

Chatbots replicate human conversations, and most chatbots use decision trees to do so. They either recognize key words and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Conversational design broadly refers to any conversation-like content, whether that comes through headers and text on a webpage, voice UI such as Google Home and Alexa, or chatbots. As such, chatbot content is one type of conversational design, but the two are not one-and-the-same. A chatbot is also not a human interacting through a chat interface (that is sometimes called “live chat”). It is specifically a computerized system.

Why does this matter? When design and engineering teams are determining the best way to communicate with their audiences, they are likely to use shorthand. I frequently hear designers say “then we [the company] will tell them [the audience] to confirm their password.” In this case, the designer may be referring to “telling” the audience via text on a page, or they may be implying a chatbot will appear to inform the audience. Early on in the concepting phase it may not matter what form of conversational design the team has in mind, but ultimately the content team will be responsible for significantly more work if the end result is a chatbot. With that in mind, it’s useful to clarify what form of conversational design the team has in mind.

One example of non-chatbot conversational design is a conversational UI. Oscar Insurance has a conversational UI, which they develop with a few best practices:

  • The headers are complete sentences.
  • Forms have help text with specific instructions (instead of examples).
  • Copy is written in the 2nd person, referring to the audience as “you”.

Voice UI can also “speak” to the audience, and if the team is considering that then they are either building a competitor to Alexa, Google Home, and Siri, or they are (more likely) building an app that these systems can download. Again, these may sound the same from a concepting perspective, but the requirements are vastly different. Voice UI has no visual design, and no ability to trigger or prompt the end-user into action. This is in stark contrast to a phone app, which may launch notifications without the end-user first opening the app.

A Chatbot Can Answer (Many) Questions

It may sound from this description as though chatbots are the perfect answer — they can launch notifications, they incorporate a visual UI, and they are conversational! Certainly, the popularity of chatbots is in part due to these benefits. But this can create an assumption that human conversation is the best way to connect with end-users. Sometimes that’s true — but not always!

In Michael J Metts’ Button talk “Sorry, I Can’t Help WIth That” he said a company must know what its goal is, and then determine if a chatbot will help fulfill that goal. This is a fantastic approach: a chatbot is a solution, and should be employed when it is the solution to a problem.

Customer service and sales are typically good goals for chatbots to fulfill. In both cases the problem may be “how might our customer service team respond quickly to common questions” or “how might our sales team help customers learn about a product or service in a quick and easy manner, without using significant employee time?” In these cases a chatbot can help people get the answers they want without needing to call and wait on hold.

However, if the problem is “how might our hospital more accurately diagnose health issues” or “how might our bank more quickly help employees find lost paychecks from their employers” a chatbot may not be appropriate. A human physician is much more accurate than a chatbot, and the end-users will pick up on that. Equally, a bank’s chatbot is unlikely to be able to connect to the numerous employers’ payroll systems required to track down paychecks. While the end-user might think they want answers from a chatbot, they’ll quickly lose trust when the chatbot can’t answer their questions.

In short, a chatbot is not a good way to handle nuances or extremely complicated situations, because of the numerous opportunities for human error. There are simply too many variables for “quick” and “accurate” to be accomplished in these situations.

A Chatbot Is Not An Algorithm

Never forget that a chatbot is only as good as its content. Yes, a chatbot is controlled by an algorithm, and can be bolstered by machine learning. But before machine learning can begin, the chatbot needs a set of rules, and needs content to speak. That’s the role of the content designer, UX writer, or content strategist to define.

We see this frequently in conversations around AI ethics. Voice assistants and chatbots are frequently identified as sexist and racially biased. They are not biased because the design and engineering team made a conscious choice to make them so. They are biased because they “reflect the biases in the viewpoints of the teams that built it,” to quote AI ethicist Josie Young in her TED talk.

For those of us building chatbots, this means we need to be consciously anti-sexist and anti-racist. We need to build chatbots thoughtfully, and not connect machine learning until after we have content designed that we want the AI to learn from. As with so many things, what a chatbot does is only half the story. It may “answer questions” — but what questions, and how? It may “direct people to their next steps” — but what are the appropriate next steps, and how does the chatbot respond when something goes wrong? In other words, what will make a true impact is how the chatbot accomplishes the things it does.

Best Practices For Engaging Chatbots

If your team is building a chatbot, hopefully you’ve already done a lot of the upfront work.

  • You’ve decided that a chatbot is the right solution.
  • You’ve identified the technological constraints, such as what system you’ll be using.
  • You’re looking into what capabilities will be available in that system, such as autocorrect or a built-in thesaurus of synonyms.

Now is when some executives say “plug it in and make it work!” and you must say “plug what in?!” As noted, your chatbot is not just an algorithm, and you have some content to design. It’s time to build the content for your chatbot. Let’s explore five best practices to make your chatbot humanesque:

  1. Define your actions.
  2. Separate your response types.
  3. Embrace your robot-self.
  4. Create a tone for each scenario.
  5. Design for errors.

1. Define Your Actions

Since a chatbot is not a magical solution to all things, you need to focus your work on specific user flows that people can accomplish with your chatbot. For example, let’s say you are building a chatbot for a company like FedEx or USPS, you may list out sample user flows like “track a package” and “update mailing address.” That means if an end-user asks the chatbot for help tracking a package, it may respond “what is the tracking number.” But the chabot should know its limitations. Perhaps one of the goals is “build trust.” Therefore if an end-user says “someone committed mail fraud in my name” the chatbot might express condolences and quickly transfer the end-user to a live customer service agent. Because the goal was to “build trust,” the team building the chatbot should recognize that anything involving sensitive information should be handled by a human — even if there is no technical or legal limitation.

There’s no one right way to go about this. Most organizations have some form of value propositions or design principles, which will help to identify the goal of the chatbot. There are also likely some requirements already defined. Therefore the goal can come from a cursory look at the requirements, and the requirements will become more specific after the goal is defined.

In an interview with Mike Bunner, VP, Director of Digital Marketing at Franklin Mint Federal Credit Union, Bunner said that without the chatbot, “our call center would be getting 3x the normal amount of calls.” Their goal could be assumed to be “decrease customer service hours.” This connects nicely to their chatbot’s initial prompt, which suggests “popular topics” that it can help with — likely these popular topics are the most common reasons people call the customer service team. In the same interview Bunner said the bot pulls its content directly from the member support content. Like many organizations, Franklin Mint had lots of helpful content, but had trouble getting people to view it.

2. Separate Your Response Types

When you think of a chatbot you likely think of one of two things:

  1. A chatbot that responds to anything an end-user types, picking up on what they want through key words and phrases.
  2. A chatbot that follows a series of decision trees, asking the end-user to select from a few options and then bringing them through a user flow.

Chatbots can do one or both of these, and it’s important to know what you’re aiming for. In fact, even if you intend to focus on decision trees, there’s the possibility of a user going off-script. With that in mind, consider how you want the chatbot to respond. If someone says “Help” or “Talk to a human” how will you route them?

As you think through the chatbot’s word associations, remember that words have context. When an end-user is editing their profile and they type in “phone number” they likely want to see where to edit their phone number. But if they’ve typed in something the chatbot doesn’t recognize, the chatbot said “I don’t understand” and then the end-user types in “phone number” they may be looking for a customer service line. This is an opportunity for engineering and content strategy to collaborate to create a well-designed and well-built bot.

This sort of thoughtful planning will come across in the end product. Adobe’s chatbot, for example, fails here. It begins by asking the end-user to freetype, but after getting a response the bot asks the end-user to select one of three options. As a user, I’m left wondering why I was asked to type if the bot couldn’t understand a simple keyword like “Adobe products”.

3. Embrace Your Robot-Self

Once you know what your chatbot can do, it’s time to think about how it will do it. First and foremost: don’t pretend that your chatbot is a human. In research with a former client, the client found that over 80% of people were comfortable interacting with a chatbot, and they liked when a chatbot had a name and personality. But those same people quickly lost faith in the bot and the organization when the chatbot pretended to be human.

One conversation with a client revolved around whether people would speak with a chatbot if they knew speaking to a human was an option. Testing found that yes, they would! In fact, reassuring end-users that a human being is available (as needed) actually increased the comfort they had in speaking to the chatbot.

The team at Hopelab had similar results when they built Vivibot, a chatbot for teens with cancer. Teens and young adults would often avoid confiding in their parents or health professionals. But Hopelab found that a chatbot removed some barriers. In their peer-reviewed randomized controlled study they were able to show that Vivibot not only provided valuable emotional support, but also improved anxiety.

Vivibot is an interesting chatbot example for several reasons. First, the bot is not intended for one-off solutions, but rather as an ongoing emotional support tool. This means the bot needed to have a variety of responses, so as to avoid sounding repetitive. Second, as a health-related bot, Vivibot needed to address sensitive subjects. She needed to be as transparent as possible, never defaulting to a generic “sounds good” for fear of alienating the people who rely on her when they don’t feel comfortable confiding in humans.

Imagine if Vivibot came across as insensitive? Emily Cummins, a writer with a piece on The Worst Chatbot Fails, shows an example where UX Magazine’s “UX Bear” asks “how would you describe the term bot to your grandma?” Emily responded “my grandma is dead,” and got back a thumbs up. This is a slightly confusing response from UX Bear, but would be potentially devastating from Vivibot.

In the near future we may see more states pass laws about bots pretending to be human, as California has. While it may seem unnecessary for the Chat Bears of the world, it’s clearly important for influential or sensitive topics, be they politics or healthcare.

4. Create A Tone For Each Scenario

When content strategists create a “voice and tone”, the two are different things. A voice is like a brand personality. It identifies how a company sounds, no matter what. The tone, however, will differ depending on the situation. The voice may be “friendly” but friendly sounds different in an error message than in a success message.

A chatbot should have a different voice from a company. It can say things like “oh no!” or “I’m happy for you.” when your company can’t. To that end, the first step of creating a chatbot voice is to develop a list of words your chatbot says. It’s important that a chatbot respond to the end-user, to let them know they’ve been heard. That means chatbots spend a lot of time saying things like “Got it” or “I understand” and you need to know what those agreement tokens sound like. Does your chatbot say “yes” or “yeah” or both? “Ok” or “okay”? “Great” or “I understand”? Parameters will help your chatbot sound consistent, such that the chatbot doesn’t respond “okie smokie” and then later “I appreciate your time,” but you’ll also need enough agreement tokens that your chatbot doesn’t sound overly robotic.

In Domino’s chatbot, the bot alternates agreement tokens like “great” and “got it”, but when it can’t understand the response it has no error token. The redundancy of the question “What city is that address in” (with no reference to the fact that it hadn’t understood my response) initially made me think the bot was broken.

5. Design For Errors

Chatbots, like other UIs, only have one chance to make a first impression. If the experience isn’t smooth and simple, people won’t return. With that in mind, a chatbot needs to have well written error messages. An error message from a chatbot may be as simple as saying “I don’t understand. Can you tell me again what you want?”, but it can also do far more.

For example, if your chatbot is an MVP, your error message may say something like “I can’t help you with that [feature] today, but ask me again in a few weeks.” Alternatively, if the end-user is asking for something the chatbot will never offer, suggest an alternative like “you can call customer service for help with that.”

Assuming you allow for free typing, there will also be the risk of someone typing a word or phrase your chatbot doesn’t understand. In that case, your chatbot may ask for clarification, or even say “I don’t understand”. But make sure you don’t leave your end-user in a loop! If the chatbot can’t understand after two or three tries, offer to put the end-user in touch with a human.

That said, error planning goes far beyond a simple “I don’t understand” or “I can’t help with that”. A well-built chatbot considers how end-users view the tasks they want to complete. Take for example a payroll system, which might use a chatbot to help employees check on their upcoming paychecks, tax deductions, and other requested pre-tax deductions. In a system like this, the chatbot is likely able to answer questions such as:

  • When is my next paycheck scheduled to be sent to me?
  • I want to set up direct deposit.
  • When can I change my 401k deductions?

It’s possible the payroll system is connected to some of the employee’s benefits — for example, it may have a flow built to allow the employee to change deductions. But the payroll chatbot team should be aware that employees may come to them with related questions and issues, such as:

  • What benefits do I have available if I go on sick leave?
  • I need to change my 401k allocations.
  • I didn’t receive my last paycheck.

It’s unlikely that the payroll system is also the benefits system. But the chatbot team needs to know that employees don’t think in terms of capabilities. They think in terms of needs. “I need to take care of my 401k” may mean going to one system to set up the deductions, and another system to change the allocations. If the chatbot says nothing but “I can’t help with that” in response, then the chatbot has failed. Our hypothetical payroll system could instead build goodwill by explaining the system to a member and recommending they speak to their HR representative.

Webflow’s Customer Support chatbot does an excellent job of not only defining what it can do, but telling the user upfront: “[I]f I’m unable to solve a problem for you, a member of our Support team will get back to you by email. Note: We don’t provide support by phone or live chat at the moment, as we’ve found it most impactful to help you via email.” You may not think of this as an error message, because it’s really about solving the problem before it ever becomes an error.

Internally, this means the team should define user flows from the end-user’s perspective, not just from the technical standpoint of what is possible. If Webflow had only considered things from their own perspective, they wouldn’t have thought to clarify what they don’t do. They would merely have solved the problems they could, and potentially left users wondering why (for example) they couldn’t find a phone number to call.

Bringing Humanity To Your Chatbot

Of course a chatbot is not a person. But it’s also not a second-choice option to a person. A chatbot can help people easily get answers to their questions, it can help them connect when they’re feeling vulnerable, and it can simplify complex processes. It is, like so many tools, a perfect solution to many potential problems.

As the creators of these chatbots, that means we have an important mission! We must create appropriate responses, humanesque tones, and helpful user flows. We must write content to respond to people in different moods, and with diverse needs — anticipating their next steps and guiding them appropriately. Most of all, we must create transparent and trustworthy bots, so that the people interacting with them can trust the information they provide.

Just remember: Define your actions, so that your chatbot accomplishes a business goal and a user need. Build out a script for your chatbot and decide if your chatbot will respond to off-script requests. Embrace your robot self and never pretend to be a human. Create a tone for each scenario. And lastly, make sure your chatbot can handle errors smoothly.

Your chatbot is a program, not a human. Still, a well-designed program can bring happiness and ease to your audience! With these five steps,your chatbot will be capable of a near-human connection with your end-user. Now it’s your turn: follow these best practices and let us know how your audience responds to your bot.

Articles on Smashing Magazine — For Web Designers And Developers

29 Jan

How To Create An Engaging And Useful Chatbot

by TBSCategories: News

Capital One. Adobe. Even Dominos has one. They’re chatbots, and they’re quickly becoming ubiquitous. A poor chatbot simply says “I’m sorry, I don’t understand” on repeat (or worse “error”.) A good chatbot feels almost-human, and helps answer questions so you don’t need to make a phone call or search the FAQ page.

But what makes a good chatbot experience? What are the table stakes that people expect from a chatbot, and what ruins that experience? In this article we’ll answer those questions and identify what you as a content designer can do to make your chatbot successful.

What Makes A Chatbot Unique?

A chatbot is a program that replicates human conversation. Most chatbots use decision trees to create a conversation. They either recognize key wuords and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Equally important to defining what a chatbot is, is identifying what it isn’t. Let’s dig into what a chatbot is — and clear up what it isn’t.

A Chatbot Is A Form Of Conversational Design

Chatbots replicate human conversations, and most chatbots use decision trees to do so. They either recognize key words and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Conversational design broadly refers to any conversation-like content, whether that comes through headers and text on a webpage, voice UI such as Google Home and Alexa, or chatbots. As such, chatbot content is one type of conversational design, but the two are not one-and-the-same. A chatbot is also not a human interacting through a chat interface (that is sometimes called “live chat”). It is specifically a computerized system.

Why does this matter? When design and engineering teams are determining the best way to communicate with their audiences, they are likely to use shorthand. I frequently hear designers say “then we [the company] will tell them [the audience] to confirm their password.” In this case, the designer may be referring to “telling” the audience via text on a page, or they may be implying a chatbot will appear to inform the audience. Early on in the concepting phase it may not matter what form of conversational design the team has in mind, but ultimately the content team will be responsible for significantly more work if the end result is a chatbot. With that in mind, it’s useful to clarify what form of conversational design the team has in mind.

One example of non-chatbot conversational design is a conversational UI. Oscar Insurance has a conversational UI, which they develop with a few best practices:

  • The headers are complete sentences.
  • Forms have help text with specific instructions (instead of examples).
  • Copy is written in the 2nd person, referring to the audience as “you”.

Voice UI can also “speak” to the audience, and if the team is considering that then they are either building a competitor to Alexa, Google Home, and Siri, or they are (more likely) building an app that these systems can download. Again, these may sound the same from a concepting perspective, but the requirements are vastly different. Voice UI has no visual design, and no ability to trigger or prompt the end-user into action. This is in stark contrast to a phone app, which may launch notifications without the end-user first opening the app.

A Chatbot Can Answer (Many) Questions

It may sound from this description as though chatbots are the perfect answer — they can launch notifications, they incorporate a visual UI, and they are conversational! Certainly, the popularity of chatbots is in part due to these benefits. But this can create an assumption that human conversation is the best way to connect with end-users. Sometimes that’s true — but not always!

In Michael J Metts’ Button talk “Sorry, I Can’t Help WIth That” he said a company must know what its goal is, and then determine if a chatbot will help fulfill that goal. This is a fantastic approach: a chatbot is a solution, and should be employed when it is the solution to a problem.

Customer service and sales are typically good goals for chatbots to fulfill. In both cases the problem may be “how might our customer service team respond quickly to common questions” or “how might our sales team help customers learn about a product or service in a quick and easy manner, without using significant employee time?” In these cases a chatbot can help people get the answers they want without needing to call and wait on hold.

However, if the problem is “how might our hospital more accurately diagnose health issues” or “how might our bank more quickly help employees find lost paychecks from their employers” a chatbot may not be appropriate. A human physician is much more accurate than a chatbot, and the end-users will pick up on that. Equally, a bank’s chatbot is unlikely to be able to connect to the numerous employers’ payroll systems required to track down paychecks. While the end-user might think they want answers from a chatbot, they’ll quickly lose trust when the chatbot can’t answer their questions.

In short, a chatbot is not a good way to handle nuances or extremely complicated situations, because of the numerous opportunities for human error. There are simply too many variables for “quick” and “accurate” to be accomplished in these situations.

A Chatbot Is Not An Algorithm

Never forget that a chatbot is only as good as its content. Yes, a chatbot is controlled by an algorithm, and can be bolstered by machine learning. But before machine learning can begin, the chatbot needs a set of rules, and needs content to speak. That’s the role of the content designer, UX writer, or content strategist to define.

We see this frequently in conversations around AI ethics. Voice assistants and chatbots are frequently identified as sexist and racially biased. They are not biased because the design and engineering team made a conscious choice to make them so. They are biased because they “reflect the biases in the viewpoints of the teams that built it,” to quote AI ethicist Josie Young in her TED talk.

For those of us building chatbots, this means we need to be consciously anti-sexist and anti-racist. We need to build chatbots thoughtfully, and not connect machine learning until after we have content designed that we want the AI to learn from. As with so many things, what a chatbot does is only half the story. It may “answer questions” — but what questions, and how? It may “direct people to their next steps” — but what are the appropriate next steps, and how does the chatbot respond when something goes wrong? In other words, what will make a true impact is how the chatbot accomplishes the things it does.

Best Practices For Engaging Chatbots

If your team is building a chatbot, hopefully you’ve already done a lot of the upfront work.

  • You’ve decided that a chatbot is the right solution.
  • You’ve identified the technological constraints, such as what system you’ll be using.
  • You’re looking into what capabilities will be available in that system, such as autocorrect or a built-in thesaurus of synonyms.

Now is when some executives say “plug it in and make it work!” and you must say “plug what in?!” As noted, your chatbot is not just an algorithm, and you have some content to design. It’s time to build the content for your chatbot. Let’s explore five best practices to make your chatbot humanesque:

  1. Define your actions.
  2. Separate your response types.
  3. Embrace your robot-self.
  4. Create a tone for each scenario.
  5. Design for errors.

1. Define Your Actions

Since a chatbot is not a magical solution to all things, you need to focus your work on specific user flows that people can accomplish with your chatbot. For example, let’s say you are building a chatbot for a company like FedEx or USPS, you may list out sample user flows like “track a package” and “update mailing address.” That means if an end-user asks the chatbot for help tracking a package, it may respond “what is the tracking number.” But the chabot should know its limitations. Perhaps one of the goals is “build trust.” Therefore if an end-user says “someone committed mail fraud in my name” the chatbot might express condolences and quickly transfer the end-user to a live customer service agent. Because the goal was to “build trust,” the team building the chatbot should recognize that anything involving sensitive information should be handled by a human — even if there is no technical or legal limitation.

There’s no one right way to go about this. Most organizations have some form of value propositions or design principles, which will help to identify the goal of the chatbot. There are also likely some requirements already defined. Therefore the goal can come from a cursory look at the requirements, and the requirements will become more specific after the goal is defined.

In an interview with Mike Bunner, VP, Director of Digital Marketing at Franklin Mint Federal Credit Union, Bunner said that without the chatbot, “our call center would be getting 3x the normal amount of calls.” Their goal could be assumed to be “decrease customer service hours.” This connects nicely to their chatbot’s initial prompt, which suggests “popular topics” that it can help with — likely these popular topics are the most common reasons people call the customer service team. In the same interview Bunner said the bot pulls its content directly from the member support content. Like many organizations, Franklin Mint had lots of helpful content, but had trouble getting people to view it.

2. Separate Your Response Types

When you think of a chatbot you likely think of one of two things:

  1. A chatbot that responds to anything an end-user types, picking up on what they want through key words and phrases.
  2. A chatbot that follows a series of decision trees, asking the end-user to select from a few options and then bringing them through a user flow.

Chatbots can do one or both of these, and it’s important to know what you’re aiming for. In fact, even if you intend to focus on decision trees, there’s the possibility of a user going off-script. With that in mind, consider how you want the chatbot to respond. If someone says “Help” or “Talk to a human” how will you route them?

As you think through the chatbot’s word associations, remember that words have context. When an end-user is editing their profile and they type in “phone number” they likely want to see where to edit their phone number. But if they’ve typed in something the chatbot doesn’t recognize, the chatbot said “I don’t understand” and then the end-user types in “phone number” they may be looking for a customer service line. This is an opportunity for engineering and content strategy to collaborate to create a well-designed and well-built bot.

This sort of thoughtful planning will come across in the end product. Adobe’s chatbot, for example, fails here. It begins by asking the end-user to freetype, but after getting a response the bot asks the end-user to select one of three options. As a user, I’m left wondering why I was asked to type if the bot couldn’t understand a simple keyword like “Adobe products”.

3. Embrace Your Robot-Self

Once you know what your chatbot can do, it’s time to think about how it will do it. First and foremost: don’t pretend that your chatbot is a human. In research with a former client, the client found that over 80% of people were comfortable interacting with a chatbot, and they liked when a chatbot had a name and personality. But those same people quickly lost faith in the bot and the organization when the chatbot pretended to be human.

One conversation with a client revolved around whether people would speak with a chatbot if they knew speaking to a human was an option. Testing found that yes, they would! In fact, reassuring end-users that a human being is available (as needed) actually increased the comfort they had in speaking to the chatbot.

The team at Hopelab had similar results when they built Vivibot, a chatbot for teens with cancer. Teens and young adults would often avoid confiding in their parents or health professionals. But Hopelab found that a chatbot removed some barriers. In their peer-reviewed randomized controlled study they were able to show that Vivibot not only provided valuable emotional support, but also improved anxiety.

Vivibot is an interesting chatbot example for several reasons. First, the bot is not intended for one-off solutions, but rather as an ongoing emotional support tool. This means the bot needed to have a variety of responses, so as to avoid sounding repetitive. Second, as a health-related bot, Vivibot needed to address sensitive subjects. She needed to be as transparent as possible, never defaulting to a generic “sounds good” for fear of alienating the people who rely on her when they don’t feel comfortable confiding in humans.

Imagine if Vivibot came across as insensitive? Emily Cummins, a writer with a piece on The Worst Chatbot Fails, shows an example where UX Magazine’s “UX Bear” asks “how would you describe the term bot to your grandma?” Emily responded “my grandma is dead,” and got back a thumbs up. This is a slightly confusing response from UX Bear, but would be potentially devastating from Vivibot.

In the near future we may see more states pass laws about bots pretending to be human, as California has. While it may seem unnecessary for the Chat Bears of the world, it’s clearly important for influential or sensitive topics, be they politics or healthcare.

4. Create A Tone For Each Scenario

When content strategists create a “voice and tone”, the two are different things. A voice is like a brand personality. It identifies how a company sounds, no matter what. The tone, however, will differ depending on the situation. The voice may be “friendly” but friendly sounds different in an error message than in a success message.

A chatbot should have a different voice from a company. It can say things like “oh no!” or “I’m happy for you.” when your company can’t. To that end, the first step of creating a chatbot voice is to develop a list of words your chatbot says. It’s important that a chatbot respond to the end-user, to let them know they’ve been heard. That means chatbots spend a lot of time saying things like “Got it” or “I understand” and you need to know what those agreement tokens sound like. Does your chatbot say “yes” or “yeah” or both? “Ok” or “okay”? “Great” or “I understand”? Parameters will help your chatbot sound consistent, such that the chatbot doesn’t respond “okie smokie” and then later “I appreciate your time,” but you’ll also need enough agreement tokens that your chatbot doesn’t sound overly robotic.

In Domino’s chatbot, the bot alternates agreement tokens like “great” and “got it”, but when it can’t understand the response it has no error token. The redundancy of the question “What city is that address in” (with no reference to the fact that it hadn’t understood my response) initially made me think the bot was broken.

5. Design For Errors

Chatbots, like other UIs, only have one chance to make a first impression. If the experience isn’t smooth and simple, people won’t return. With that in mind, a chatbot needs to have well written error messages. An error message from a chatbot may be as simple as saying “I don’t understand. Can you tell me again what you want?”, but it can also do far more.

For example, if your chatbot is an MVP, your error message may say something like “I can’t help you with that [feature] today, but ask me again in a few weeks.” Alternatively, if the end-user is asking for something the chatbot will never offer, suggest an alternative like “you can call customer service for help with that.”

Assuming you allow for free typing, there will also be the risk of someone typing a word or phrase your chatbot doesn’t understand. In that case, your chatbot may ask for clarification, or even say “I don’t understand”. But make sure you don’t leave your end-user in a loop! If the chatbot can’t understand after two or three tries, offer to put the end-user in touch with a human.

That said, error planning goes far beyond a simple “I don’t understand” or “I can’t help with that”. A well-built chatbot considers how end-users view the tasks they want to complete. Take for example a payroll system, which might use a chatbot to help employees check on their upcoming paychecks, tax deductions, and other requested pre-tax deductions. In a system like this, the chatbot is likely able to answer questions such as:

  • When is my next paycheck scheduled to be sent to me?
  • I want to set up direct deposit.
  • When can I change my 401k deductions?

It’s possible the payroll system is connected to some of the employee’s benefits — for example, it may have a flow built to allow the employee to change deductions. But the payroll chatbot team should be aware that employees may come to them with related questions and issues, such as:

  • What benefits do I have available if I go on sick leave?
  • I need to change my 401k allocations.
  • I didn’t receive my last paycheck.

It’s unlikely that the payroll system is also the benefits system. But the chatbot team needs to know that employees don’t think in terms of capabilities. They think in terms of needs. “I need to take care of my 401k” may mean going to one system to set up the deductions, and another system to change the allocations. If the chatbot says nothing but “I can’t help with that” in response, then the chatbot has failed. Our hypothetical payroll system could instead build goodwill by explaining the system to a member and recommending they speak to their HR representative.

Webflow’s Customer Support chatbot does an excellent job of not only defining what it can do, but telling the user upfront: “[I]f I’m unable to solve a problem for you, a member of our Support team will get back to you by email. Note: We don’t provide support by phone or live chat at the moment, as we’ve found it most impactful to help you via email.” You may not think of this as an error message, because it’s really about solving the problem before it ever becomes an error.

Internally, this means the team should define user flows from the end-user’s perspective, not just from the technical standpoint of what is possible. If Webflow had only considered things from their own perspective, they wouldn’t have thought to clarify what they don’t do. They would merely have solved the problems they could, and potentially left users wondering why (for example) they couldn’t find a phone number to call.

Bringing Humanity To Your Chatbot

Of course a chatbot is not a person. But it’s also not a second-choice option to a person. A chatbot can help people easily get answers to their questions, it can help them connect when they’re feeling vulnerable, and it can simplify complex processes. It is, like so many tools, a perfect solution to many potential problems.

As the creators of these chatbots, that means we have an important mission! We must create appropriate responses, humanesque tones, and helpful user flows. We must write content to respond to people in different moods, and with diverse needs — anticipating their next steps and guiding them appropriately. Most of all, we must create transparent and trustworthy bots, so that the people interacting with them can trust the information they provide.

Just remember: Define your actions, so that your chatbot accomplishes a business goal and a user need. Build out a script for your chatbot and decide if your chatbot will respond to off-script requests. Embrace your robot self and never pretend to be a human. Create a tone for each scenario. And lastly, make sure your chatbot can handle errors smoothly.

Your chatbot is a program, not a human. Still, a well-designed program can bring happiness and ease to your audience! With these five steps,your chatbot will be capable of a near-human connection with your end-user. Now it’s your turn: follow these best practices and let us know how your audience responds to your bot.

Articles on Smashing Magazine — For Web Designers And Developers

28 Jan

How To Create An Engaging And Useful Chatbot

by TBSCategories: News

Capital One. Adobe. Even Dominos has one. They’re chatbots, and they’re quickly becoming ubiquitous. A poor chatbot simply says “I’m sorry, I don’t understand” on repeat (or worse “error”.) A good chatbot feels almost-human, and helps answer questions so you don’t need to make a phone call or search the FAQ page.

But what makes a good chatbot experience? What are the table stakes that people expect from a chatbot, and what ruins that experience? In this article we’ll answer those questions and identify what you as a content designer can do to make your chatbot successful.

What Makes A Chatbot Unique?

A chatbot is a program that replicates human conversation. Most chatbots use decision trees to create a conversation. They either recognize key wuords and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Equally important to defining what a chatbot is, is identifying what it isn’t. Let’s dig into what a chatbot is — and clear up what it isn’t.

A Chatbot Is A Form Of Conversational Design

Chatbots replicate human conversations, and most chatbots use decision trees to do so. They either recognize key words and respond accordingly, or they allow the end-user to select from options to direct the conversation.

Conversational design broadly refers to any conversation-like content, whether that comes through headers and text on a webpage, voice UI such as Google Home and Alexa, or chatbots. As such, chatbot content is one type of conversational design, but the two are not one-and-the-same. A chatbot is also not a human interacting through a chat interface (that is sometimes called “live chat”). It is specifically a computerized system.

Why does this matter? When design and engineering teams are determining the best way to communicate with their audiences, they are likely to use shorthand. I frequently hear designers say “then we [the company] will tell them [the audience] to confirm their password.” In this case, the designer may be referring to “telling” the audience via text on a page, or they may be implying a chatbot will appear to inform the audience. Early on in the concepting phase it may not matter what form of conversational design the team has in mind, but ultimately the content team will be responsible for significantly more work if the end result is a chatbot. With that in mind, it’s useful to clarify what form of conversational design the team has in mind.

One example of non-chatbot conversational design is a conversational UI. Oscar Insurance has a conversational UI, which they develop with a few best practices:

  • The headers are complete sentences.
  • Forms have help text with specific instructions (instead of examples).
  • Copy is written in the 2nd person, referring to the audience as “you”.

Voice UI can also “speak” to the audience, and if the team is considering that then they are either building a competitor to Alexa, Google Home, and Siri, or they are (more likely) building an app that these systems can download. Again, these may sound the same from a concepting perspective, but the requirements are vastly different. Voice UI has no visual design, and no ability to trigger or prompt the end-user into action. This is in stark contrast to a phone app, which may launch notifications without the end-user first opening the app.

A Chatbot Can Answer (Many) Questions

It may sound from this description as though chatbots are the perfect answer — they can launch notifications, they incorporate a visual UI, and they are conversational! Certainly, the popularity of chatbots is in part due to these benefits. But this can create an assumption that human conversation is the best way to connect with end-users. Sometimes that’s true — but not always!

In Michael J Metts’ Button talk “Sorry, I Can’t Help WIth That” he said a company must know what its goal is, and then determine if a chatbot will help fulfill that goal. This is a fantastic approach: a chatbot is a solution, and should be employed when it is the solution to a problem.

Customer service and sales are typically good goals for chatbots to fulfill. In both cases the problem may be “how might our customer service team respond quickly to common questions” or “how might our sales team help customers learn about a product or service in a quick and easy manner, without using significant employee time?” In these cases a chatbot can help people get the answers they want without needing to call and wait on hold.

However, if the problem is “how might our hospital more accurately diagnose health issues” or “how might our bank more quickly help employees find lost paychecks from their employers” a chatbot may not be appropriate. A human physician is much more accurate than a chatbot, and the end-users will pick up on that. Equally, a bank’s chatbot is unlikely to be able to connect to the numerous employers’ payroll systems required to track down paychecks. While the end-user might think they want answers from a chatbot, they’ll quickly lose trust when the chatbot can’t answer their questions.

In short, a chatbot is not a good way to handle nuances or extremely complicated situations, because of the numerous opportunities for human error. There are simply too many variables for “quick” and “accurate” to be accomplished in these situations.

A Chatbot Is Not An Algorithm

Never forget that a chatbot is only as good as its content. Yes, a chatbot is controlled by an algorithm, and can be bolstered by machine learning. But before machine learning can begin, the chatbot needs a set of rules, and needs content to speak. That’s the role of the content designer, UX writer, or content strategist to define.

We see this frequently in conversations around AI ethics. Voice assistants and chatbots are frequently identified as sexist and racially biased. They are not biased because the design and engineering team made a conscious choice to make them so. They are biased because they “reflect the biases in the viewpoints of the teams that built it,” to quote AI ethicist Josie Young in her TED talk.

For those of us building chatbots, this means we need to be consciously anti-sexist and anti-racist. We need to build chatbots thoughtfully, and not connect machine learning until after we have content designed that we want the AI to learn from. As with so many things, what a chatbot does is only half the story. It may “answer questions” — but what questions, and how? It may “direct people to their next steps” — but what are the appropriate next steps, and how does the chatbot respond when something goes wrong? In other words, what will make a true impact is how the chatbot accomplishes the things it does.

Best Practices For Engaging Chatbots

If your team is building a chatbot, hopefully you’ve already done a lot of the upfront work.

  • You’ve decided that a chatbot is the right solution.
  • You’ve identified the technological constraints, such as what system you’ll be using.
  • You’re looking into what capabilities will be available in that system, such as autocorrect or a built-in thesaurus of synonyms.

Now is when some executives say “plug it in and make it work!” and you must say “plug what in?!” As noted, your chatbot is not just an algorithm, and you have some content to design. It’s time to build the content for your chatbot. Let’s explore five best practices to make your chatbot humanesque:

  1. Define your actions.
  2. Separate your response types.
  3. Embrace your robot-self.
  4. Create a tone for each scenario.
  5. Design for errors.

1. Define Your Actions

Since a chatbot is not a magical solution to all things, you need to focus your work on specific user flows that people can accomplish with your chatbot. For example, let’s say you are building a chatbot for a company like FedEx or USPS, you may list out sample user flows like “track a package” and “update mailing address.” That means if an end-user asks the chatbot for help tracking a package, it may respond “what is the tracking number.” But the chabot should know its limitations. Perhaps one of the goals is “build trust.” Therefore if an end-user says “someone committed mail fraud in my name” the chatbot might express condolences and quickly transfer the end-user to a live customer service agent. Because the goal was to “build trust,” the team building the chatbot should recognize that anything involving sensitive information should be handled by a human — even if there is no technical or legal limitation.

There’s no one right way to go about this. Most organizations have some form of value propositions or design principles, which will help to identify the goal of the chatbot. There are also likely some requirements already defined. Therefore the goal can come from a cursory look at the requirements, and the requirements will become more specific after the goal is defined.

In an interview with Mike Bunner, VP, Director of Digital Marketing at Franklin Mint Federal Credit Union, Bunner said that without the chatbot, “our call center would be getting 3x the normal amount of calls.” Their goal could be assumed to be “decrease customer service hours.” This connects nicely to their chatbot’s initial prompt, which suggests “popular topics” that it can help with — likely these popular topics are the most common reasons people call the customer service team. In the same interview Bunner said the bot pulls its content directly from the member support content. Like many organizations, Franklin Mint had lots of helpful content, but had trouble getting people to view it.

2. Separate Your Response Types

When you think of a chatbot you likely think of one of two things:

  1. A chatbot that responds to anything an end-user types, picking up on what they want through key words and phrases.
  2. A chatbot that follows a series of decision trees, asking the end-user to select from a few options and then bringing them through a user flow.

Chatbots can do one or both of these, and it’s important to know what you’re aiming for. In fact, even if you intend to focus on decision trees, there’s the possibility of a user going off-script. With that in mind, consider how you want the chatbot to respond. If someone says “Help” or “Talk to a human” how will you route them?

As you think through the chatbot’s word associations, remember that words have context. When an end-user is editing their profile and they type in “phone number” they likely want to see where to edit their phone number. But if they’ve typed in something the chatbot doesn’t recognize, the chatbot said “I don’t understand” and then the end-user types in “phone number” they may be looking for a customer service line. This is an opportunity for engineering and content strategy to collaborate to create a well-designed and well-built bot.

This sort of thoughtful planning will come across in the end product. Adobe’s chatbot, for example, fails here. It begins by asking the end-user to freetype, but after getting a response the bot asks the end-user to select one of three options. As a user, I’m left wondering why I was asked to type if the bot couldn’t understand a simple keyword like “Adobe products”.

3. Embrace Your Robot-Self

Once you know what your chatbot can do, it’s time to think about how it will do it. First and foremost: don’t pretend that your chatbot is a human. In research with a former client, the client found that over 80% of people were comfortable interacting with a chatbot, and they liked when a chatbot had a name and personality. But those same people quickly lost faith in the bot and the organization when the chatbot pretended to be human.

One conversation with a client revolved around whether people would speak with a chatbot if they knew speaking to a human was an option. Testing found that yes, they would! In fact, reassuring end-users that a human being is available (as needed) actually increased the comfort they had in speaking to the chatbot.

The team at Hopelab had similar results when they built Vivibot, a chatbot for teens with cancer. Teens and young adults would often avoid confiding in their parents or health professionals. But Hopelab found that a chatbot removed some barriers. In their peer-reviewed randomized controlled study they were able to show that Vivibot not only provided valuable emotional support, but also improved anxiety.

Vivibot is an interesting chatbot example for several reasons. First, the bot is not intended for one-off solutions, but rather as an ongoing emotional support tool. This means the bot needed to have a variety of responses, so as to avoid sounding repetitive. Second, as a health-related bot, Vivibot needed to address sensitive subjects. She needed to be as transparent as possible, never defaulting to a generic “sounds good” for fear of alienating the people who rely on her when they don’t feel comfortable confiding in humans.

Imagine if Vivibot came across as insensitive? Emily Cummins, a writer with a piece on The Worst Chatbot Fails, shows an example where UX Magazine’s “UX Bear” asks “how would you describe the term bot to your grandma?” Emily responded “my grandma is dead,” and got back a thumbs up. This is a slightly confusing response from UX Bear, but would be potentially devastating from Vivibot.

In the near future we may see more states pass laws about bots pretending to be human, as California has. While it may seem unnecessary for the Chat Bears of the world, it’s clearly important for influential or sensitive topics, be they politics or healthcare.

4. Create A Tone For Each Scenario

When content strategists create a “voice and tone”, the two are different things. A voice is like a brand personality. It identifies how a company sounds, no matter what. The tone, however, will differ depending on the situation. The voice may be “friendly” but friendly sounds different in an error message than in a success message.

A chatbot should have a different voice from a company. It can say things like “oh no!” or “I’m happy for you.” when your company can’t. To that end, the first step of creating a chatbot voice is to develop a list of words your chatbot says. It’s important that a chatbot respond to the end-user, to let them know they’ve been heard. That means chatbots spend a lot of time saying things like “Got it” or “I understand” and you need to know what those agreement tokens sound like. Does your chatbot say “yes” or “yeah” or both? “Ok” or “okay”? “Great” or “I understand”? Parameters will help your chatbot sound consistent, such that the chatbot doesn’t respond “okie smokie” and then later “I appreciate your time,” but you’ll also need enough agreement tokens that your chatbot doesn’t sound overly robotic.

In Domino’s chatbot, the bot alternates agreement tokens like “great” and “got it”, but when it can’t understand the response it has no error token. The redundancy of the question “What city is that address in” (with no reference to the fact that it hadn’t understood my response) initially made me think the bot was broken.

5. Design For Errors

Chatbots, like other UIs, only have one chance to make a first impression. If the experience isn’t smooth and simple, people won’t return. With that in mind, a chatbot needs to have well written error messages. An error message from a chatbot may be as simple as saying “I don’t understand. Can you tell me again what you want?”, but it can also do far more.

For example, if your chatbot is an MVP, your error message may say something like “I can’t help you with that [feature] today, but ask me again in a few weeks.” Alternatively, if the end-user is asking for something the chatbot will never offer, suggest an alternative like “you can call customer service for help with that.”

Assuming you allow for free typing, there will also be the risk of someone typing a word or phrase your chatbot doesn’t understand. In that case, your chatbot may ask for clarification, or even say “I don’t understand”. But make sure you don’t leave your end-user in a loop! If the chatbot can’t understand after two or three tries, offer to put the end-user in touch with a human.

That said, error planning goes far beyond a simple “I don’t understand” or “I can’t help with that”. A well-built chatbot considers how end-users view the tasks they want to complete. Take for example a payroll system, which might use a chatbot to help employees check on their upcoming paychecks, tax deductions, and other requested pre-tax deductions. In a system like this, the chatbot is likely able to answer questions such as:

  • When is my next paycheck scheduled to be sent to me?
  • I want to set up direct deposit.
  • When can I change my 401k deductions?

It’s possible the payroll system is connected to some of the employee’s benefits — for example, it may have a flow built to allow the employee to change deductions. But the payroll chatbot team should be aware that employees may come to them with related questions and issues, such as:

  • What benefits do I have available if I go on sick leave?
  • I need to change my 401k allocations.
  • I didn’t receive my last paycheck.

It’s unlikely that the payroll system is also the benefits system. But the chatbot team needs to know that employees don’t think in terms of capabilities. They think in terms of needs. “I need to take care of my 401k” may mean going to one system to set up the deductions, and another system to change the allocations. If the chatbot says nothing but “I can’t help with that” in response, then the chatbot has failed. Our hypothetical payroll system could instead build goodwill by explaining the system to a member and recommending they speak to their HR representative.

Webflow’s Customer Support chatbot does an excellent job of not only defining what it can do, but telling the user upfront: “[I]f I’m unable to solve a problem for you, a member of our Support team will get back to you by email. Note: We don’t provide support by phone or live chat at the moment, as we’ve found it most impactful to help you via email.” You may not think of this as an error message, because it’s really about solving the problem before it ever becomes an error.

Internally, this means the team should define user flows from the end-user’s perspective, not just from the technical standpoint of what is possible. If Webflow had only considered things from their own perspective, they wouldn’t have thought to clarify what they don’t do. They would merely have solved the problems they could, and potentially left users wondering why (for example) they couldn’t find a phone number to call.

Bringing Humanity To Your Chatbot

Of course a chatbot is not a person. But it’s also not a second-choice option to a person. A chatbot can help people easily get answers to their questions, it can help them connect when they’re feeling vulnerable, and it can simplify complex processes. It is, like so many tools, a perfect solution to many potential problems.

As the creators of these chatbots, that means we have an important mission! We must create appropriate responses, humanesque tones, and helpful user flows. We must write content to respond to people in different moods, and with diverse needs — anticipating their next steps and guiding them appropriately. Most of all, we must create transparent and trustworthy bots, so that the people interacting with them can trust the information they provide.

Just remember: Define your actions, so that your chatbot accomplishes a business goal and a user need. Build out a script for your chatbot and decide if your chatbot will respond to off-script requests. Embrace your robot self and never pretend to be a human. Create a tone for each scenario. And lastly, make sure your chatbot can handle errors smoothly.

Your chatbot is a program, not a human. Still, a well-designed program can bring happiness and ease to your audience! With these five steps,your chatbot will be capable of a near-human connection with your end-user. Now it’s your turn: follow these best practices and let us know how your audience responds to your bot.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
design-remote
25 Jan

Making Remote Work Work: Useful Tools And Resources

by TBSCategories: News

Remote work brings along entirely different challenges than working from an office. Maybe your internet connection is rather slow? Maybe it’s too quiet around you to focus? Or too loud for a virtual client meeting? A lot of things influence the way we work. But it’s not only the environment around us and the technical equipment, remote work also means that you might need to rethink your and your team’s workflow.

In this post, we compiled some useful tools and resources to help you tackle some of the challenges of working remotely. The collection is by no means complete, but rather a selection of things that we found useful and that we hope will make your day-to-day work more productive and efficient, too.

If you are interested in more tools like these ones, please kindly take a look at our lovely email newsletter, and get tips like these ones right in your inbox.

Make Design Strive Despite The Distance

One fantastic resource we came across comes from the folks at InVision: Drawing from their experience of working remotely with 700 employees spread across 30 countries and no single office, they published a free eBook Remote Work for Design Teams with valuable tips for making design thrive despite the distance.

A lovely free eBook on “Remote Work for Design Teams”, fully available as HTML book, too.

Also, their list of essential resources for remote design teams also features great tips to help remote teams foster creativity, aid collaboration, and stay focused.

Sounds To Help You Focus

Speaking of staying focused: From a psychological perspective, this might easily be one of the biggest challenges when you need to get work done in a place that, well, doesn’t feel like work. If you’re missing the familiar office sounds when working from home, I Miss The Office brings some office atmosphere into your home office — with virtual colleagues who produce typical sounds like typing, squeaking chairs, or the occasional bubbling of the watercooler. Truth be told, not everyone’s too fond of these kinds of sounds, so maybe Noizio is for you? The app lets you mix nature and city sounds to create your personal ambient sound.

Another approach to increasing focus with sound comes from Brain.fm. Their team of scientists, musicians, and developers designs functional music that affects the brain to achieve the desired mental state. Focus@Will is also based on neuroscience and helps you focus by changing the characteristics of music at the right time intervals. Maybe some nice variety to your usual work playlist?

Remove Background Noises From Your Calls

While some sounds have positive effects on us and our work, others distract us. The dog barking, kids screaming, or a construction site right outside your window — there are a lot of noises that not only interrupt your flow but also calls and virtual meetings. Luckily, AI is here to help.

The AI-powered tool Krisp removes background noises from you to other call participants when you speak, and the other way around. Whether you want to have disruption-free virtual meetings or plan to record a podcast even though your apartment is located on a busy street, Krisp works in over 800 conferencing, voice messaging, streaming, and recording apps. Audio processing happens locally, by the way, so no voice or audio will leave your device.

Schedule Calls With Ease

Scheduling meetings and team calls usually involves a lot of back-and-forth emails. And these do not only take up quite some time but they can also become confusing quite easily depending on how many people (and timezones!) are involved. Calendly is here to change that.

The idea: You set up your availability preferences and share the link with your colleagues, clients, or whoever else you want to meet with. The invitees can then pick a time slot following the rules you created and the event will automatically be added to all of your calendars (Google, Outlook, Office 365, and iCloud calendars are supported). Seamless timezone detection ensures everyone’s on the same page. Looking for an alternative? SavvyCal is wonderful, too.

Stick To The Schedule

To help you make sure your calls stay on track, Big Timer is a fantastic little tool. The bold yet minimalist timer counts down the remaining minutes right in your browser window — and even if you accidentally close the browser tab or need to restart your device, it will take the disruption into account. Keyboard shortcuts make it easy to adjust the duration and pause or stop the countdown.

Record Video Messages Of Your Screen

Sometimes schedules don’t align and there’s no slot for a quick video call to give context to your code review or share your thoughts on a design decision. However, typing walls of text often isn’t the ideal solution either. That’s where Loom comes in. It provides a quick and easy way to record video messages of your screen, cam, or both when written words just aren’t enough.

Take Your Screenshots To The Next Level

How many screnshots do you take each day? To show a bug to a colleague or give feedback on a project, for example? If you’re a Mac user and have relied on the built-in screenshot-taking features until now, CleanShot X might be a powerful replacement.

CleanShot X not only supports scrolling and offers annotation tools to highlight important parts of your screenshots, it also makes sharing a breeze: You can instantly save, copy, or drag and drop screenshots and screen recordings to other apps or copy a shareable link. A nice detail: If your desktop is cluttered when taking a screenshot, CleanShot X hides all icons to prevent distractions.

Solve Your Timezone Pain

When teams are spread across the globe, keeping an eye on timezones is crucial to make collaboration work. After all, no one wants to get pinged when they are still asleep. A little tool to help you wrangle different timezones is FIO. The site displays the time of your preferred locations as a beautiful color gradient. FIO is also available as a Chrome extension.

Get The Most Out Of Your Data Connection

Remote work can turn out to be a true stress test for your data connection, and with automatic updates, online backups, cloud syncs, and various apps running on your device, there’s a lot of data usage going on in the background, too. Keeping track of your device’s data usage is always a good idea — also to identify suspicious data exchange with third parties.

For Mac users, the TripMode app helps you control and optimize data usage. It measures all the traffic on your Mac and blocks apps by default if you don’t grant them access. To browse faster, improve the quality of your team calls, or to prevent distractions, you can set custom profiles for work, video calls, streaming, or whatever else you plan to do.

Untangle Your Bookmark Mess

Do you have a dedicated system for storing all those useful tools and articles that might come in handy someday? If your bookmarks are overflowing with precious goodies but you’ve lost track of them, Raindrop.io is just waiting to help untangle that bookmark mess.

Raindrop.io lets you sort your bookmarks into collections and assign tags to them that make it easier to quickly find what you’re looking for, and, if you want, you can even share these collections with team members and friends. The tool works seamlessly across devices and is also available in a premium version that comes with additional features such as a duplicate and broken link finder, full-text search for the websites you saved, a Cloud backup, and more.

Learn To Say No

Last but not least, we all know how hard it can be to say no — no matter if it’s to a project, a meeting, a phone call, a guest post, to pushy sales people, or anything else you don’t have the time for or don’t feel comfortable with. “How To Say No” has got your back in those situations, with useful email templates that help you find the right words. Not only when working remotely.

Wrapping Up

We hope that these resources will help remove some of the friction that you might have encountered when working remotely so that you can focus on what really matters: Do fantastic work. Happy remote working!

By the way, if you’re up for more bite-sized tips, tools, and resources to ease your live as a designer or developer, we send out a weekly email newsletter dedicated to a new topic every Tuesday. Each issue is hand-curated by us, the Smashing team, and written and edited with love and care.

Please feel free to browse previous issues — in the past few weeks, we covered UX, CSS, HTML emails, web font loading, and web performance, for example. Thank you for your kind and ongoing support, everyone. ❤️

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
19 Nov

Useful Tools In Vue.js Web Development

by TBSCategories: News

When working on a new project, there are certain features that are necessary depending on how the application is supposed to be used. For example, if you’ll be storing user-specific data, you’ll need to handle authentications, this will require the setting up of a form that needs to be validated. Things such as authentication and form validations are common; there are solutions that possibly fit your use case.

To properly utilize your development time, it is better you use what is available, instead of inventing yours.

As a new developer, there’s the possibility that you won’t be aware of all that the Vue ecosystem provides you. This article will help with that; it will cover certain useful tools that will aid you in building better Vue applications.

Note: There are alternatives to these libraries and this article is in no way placing these few over the others. They are just the ones I’ve worked with.

This tutorial is aimed at beginners that either just started learning about Vue or already have basic knowledge of Vue. All code snippets used in this tutorial can be found on my GitHub.

Vue-notification

During user interaction, there is often a need to display a success message, error message, or random info to the user. In this section, we’re going to look at how to display messages and warnings to your user using vue-notification. This package provides an interface with a nice animation/transition for displaying errors, general information, and success messages to your user across your application and it does not require a lot of configuration to get up and running.

Installation

You can install vue-notification in your project using either Yarn or NPM depending on the package manager for your project

Yarn
yarn add vue-notification
npm
npm install --save vue-notification

After the installation is complete, the next thing would be to add it to the entry point in your app, the main.js file.

main.js
//several lines of existing code in the file     import Notifications from 'vue-notification'     Vue.use(Notifications)

At this point, we only need to add the notifications component in the App.vue file before we can display notifications in our app. The reason why we’re adding this component to the App.vue file is to avoid repetition in our application because no matter the page the user is on in our app, components in App.vue (e.g the header & footer components) would always be available. This takes the pain of having to register the notification component in every file that we need to display a notification to the user.

App.vue
<template>   <div id="app">     <div id="nav">       <router-link to="/">Home</router-link> |       <router-link to="/about">Notifications</router-link>     </div>     <notifications group="demo"/>     <router-view />   </div> </template>

Here, we add one instance of this component which accepts a group prop which would be used in grouping the different types of notifications we have. This is because the notifications component accepts a number of props that dictate how the component behaves and we’re going to look at a few of these.

  1. group
    This prop is used to specify the different types of notifications you might have in your app. For instance, you might decide to use different styles and behavior depending on what purpose the notification is supposed to serve, form validation, API response, etc.
  2. type
    This prop accepts a value that serves as a ‘class name’ for each notification type we have in our application and examples can include success, error, and warn. If we use any one of these as a notification type, we can easily style the component by using this class format vue-notification + '.' + type, i.e .vue-notification.warn for warn, and so on.
  3. duration
    This prop specifies how long the notification component should appear before disappearing. It accepts a number as a value in ms and also accepts a negative number (-1) if you want it to remain on your user’s screen till they click on it.
  4. position
    This prop is used in setting the position you want notifications to appear from in your app. Some of the available options are top left, top right, top center, bottom right, bottom left, and bottom center.

We can add these props to our component in App.vue so it now looks like this;

<template>   <div id="app">     <div id="nav">       <router-link to="/">Home</router-link> |       <router-link to="/about">Notifications</router-link>     </div>     <notifications       :group="group"       :type="type"       :duration="duration"       :position="position"     />     <router-view />   </div> </template> <script>   export default {     data() {       return {         duration: -1,         group: "demo",         position: "top center",         type: "info",       };     },   }; </script> <style>   .vue-notification.info {     border-left: 0;     background-color: orange;   }   .vue-notification.success {     border-left: 0;     background-color: limegreen;   }   .vue-notification.error {     border-left: 0;     background-color: red;   } </style>

We also add styling for the different notification types that we would be using in our application. Note that other than group, we can pass each of the remaining props on the fly whenever we want to display a notification and it would still work accordingly. To display a notification in any of your Vue files, you can do the following.

vueFile.vue
this.$  notify({   group: "demo",   type: "error",   text: "This is an error notification", });

Here, we create a notification of type error under the group notification of demo. The property text accepts the message you want the notification to contain and in this case, the message is ‘This is an error notification’. This is what the notification would look like in your app.

You can find out the other available props and other ways to configure the notification on the official docs page.

Vuelidate

One of the most common elements used on the web are form elements (input[type='text'], input[type='email'], input[type='password'], and so on) and there is always a need to validate user input to make sure they’re sending the right data and/or using the right format in the input field. With Vuelidate, you can add validation to the forms in your Vue.js application, saving time and benefitting from the time put into this package. I had been hearing about Vuelidate for a while but I was a little reluctant to take a look at it because I thought it would be too complex which meant I was writing validations from scratch for most of the form fields in the apps I worked on.

When I eventually looked at the docs, I found out it was not difficult to get started with and I could validate my form fields in no time and move on to the next thing.

Installation

You can install Vuelidate using any of the following package managers.

Yarn
yarn add vuelidate
npm
npm install vuelidate --save

After installation, the next thing would be to add it to your app’s config in the main.js file so you can use it in your vue files.

import Vuelidate from 'vuelidate' Vue.use(Vuelidate)

Assuming you have a form that looks like this in your app;

vuelidate.vue
<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />     </div>     <input type="submit" value="LOGIN" class="input__button" />     <p class="confirmation__text" v-if="submitted">Form clicked</p>   </form> </template> <script>   export default {     data() {       return {         submitted: false,         form: {           email: null,           fullName: null,           age: null,           password: null,         },       };     },     methods: {       login() {         this.submitted = true;       },     },   }; </script>

Now to validate this type of form, you first need to decide on what type of validation you need for each form field. For instance, you can decide you need the minimum length of the fullName to be 10 and the minimum age to be 18.

Vuelidate comes with built-in validators that we only need to import it to use. We can also choose to validate the password field based on a particular format, e.g Password should contain at least a lower case letter, an upper case letter, and a special character. We can write our own little validator that does this and plug it into the list of Vuelidate’s plugin.

Let’s take it step by step.

Using Built-In Validators
<script>   import {     required,     minLength,     minValue,     email,   } from "vuelidate/lib/validators";   export default {     validations: {       form: {         email: {           email,           required,         },         fullName: {           minLength: minLength(10),           required,         },         age: {           required,           minValue: minValue(18),         },       },     },   }; </script>

Here, we import some validators that we need to properly validate our form. We also add a validations property where we define the validation rules for each form field that we want to validate.

At this point, if you inspect the devTools for your app, you should see something that looks like this;

The $ v computed property contains a number of methods that are useful in confirming the validity of our form but we’re only going to focus on a few of them:

  1. $ invalid
    To check if the form passes all validation.
  2. email
    To check that the value is a valid email address.
  3. minValue
    To check that the value of age passes the minValue check.
  4. minLength
    To verify the length of fullName.
  5. required
    To ensure all required fields are provided.

If you enter a value for age less than the minimum age set in the validation and check $ v.form.age.minValue, it would be set to false and this means the value in the input field doesn’t pass the minValue validation check.

Using Custom Validators

We also need to validate our password field and ensure it contains the required format but Vuelidate does not have a built-in validator that we can use to achieve this. We can write our own custom validator that does this using RegEx. This custom validator would look like this;

<script>   import {     required,     minLength,     minValue,     email,   } from "vuelidate/lib/validators";   export default {     validations: {       form: { //existing validator rules         password: {           required,           validPassword(password) {             let regExp = /^(?=.[0-9])(?=.[!@#$  %^&])(?=.[A-Z]+)[a-zA-Z0-9!@#$  %^&*]{6,}$  /;             return regExp.test(password);           },         },       },     },   }; </script>

Here, we create a custom validator that uses a Regex to check that the password contains the following;

  1. At least one uppercase letter;
  2. At least one lowercase letter;
  3. At least one special character;
  4. At least one number;
  5. Must have a minimum length of 6.

If you try to enter any password that doesn’t meet any of the requirements listed above, the validPassword would be set to false.

Now that we’re sure our validations are working, we have to display the appropriate error messages so the user knows why they can’t proceed. This would look like this:

<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.fullName.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.email.required">         This field is required       </p>       <p class="error__text" v-if="!$  v.form.email.email">         This email is invalid       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.age.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.password.required">         This field is required       </p>       <p class="error__text" v-else-if="!$  v.form.password.validPassword">         Password should contain at least a lower case letter, an upper case         letter, a number and a special character       </p>     </div>     <input type="submit" value="LOGIN" class="input__button" />   </form> </template>

Here, we add a paragraph that displays either a text telling the user that a field is required, an inputted value for email is not valid or that the password doesn’t contain the required characters. If we look at this in your browser, you would see the errors already appearing under each input field.

This is bad for user experience as the user is yet to interact with the form and as such the error texts should not be visible at least, till the user tries to submit the form. To fix this, we would add submitted to the condition required for the error texts to show and also switch the value of submitted to true when the user clicks on the submit button.

<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.fullName.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.email.required">         This field is required       </p>       <p class="error__text" v-if="submitted && !$  v.form.email.email">         This email is invalid       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.age.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.password.required">         This field is required       </p>       <p         class="error__text"         v-else-if="submitted && !$  v.form.password.validPassword"       >         Password should contain at least a lower case letter, an upper case         letter, a number and a special character       </p>     </div>     <input type="submit" value="LOGIN" class="input__button" />   </form> </template>

Now the error texts do not appear until the user clicks on the submit button and this is much better for the user. Each validation error would appear if the value inputted in the form does not satisfy the validation.

Finally, we would only want to process the user’s input when all validations on our form have passed and one way we can do this would be to use the $ invalid property on the form which is present in the $ v computed property. Let us take a look at how to do that:

methods: {       login() {         this.submitted = true;         let invalidForm = this.$  v.form.$  invalid;         //check that every field in this form has been entered correctly.         if (!invalidForm) {           // process the form data         }       },     },

Here, we’re checking to ensure that the form has been completely filled and filled correctly. If it returns false, that means the form is valid and we can process the data from the form but if it is true , it means that the form is still invalid and the user still needs to tend to some errors in the form. We can also use this property to disable or style the submit button depending on your preference.

Vuex-persistedstate

During development, there are instances where you would store data like a user’s info and token in your Vuex store. But your Vuex store data would not persist if your users try to refresh your app from the browser or enter a new route from the URL tab of your browser and the current state of your application gets lost with it. This causes the user to be redirected to the login page if the route is being protected with navigation guard which is abnormal behavior for your app to have. This can be fixed with vuex-persistedstate, let look at how.

Installation

You can install this plugin using any one of the two methods:

Yarn
yarn add vuex-persistedstate
npm
npm install --save vuex-persistedstate

After the installation process is complete, the next step would be to configure this plugin to be ready for use in your Vuex store.

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {},     mutations: {},     actions: {},     modules: {},     plugins: [createPersistedState()] })

At this point, all of our Vuex Store would be stored in localStorage (by default) but vuex-persistedstate comes with the option to use sessionStorage or cookies.

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {},     mutations: {},     actions: {},     modules: {},   // changes storage to sessionStorage     plugins: [createPersistedState({ storage: window.sessionStorage }); ] })

To confirm that our Store would persist after refreshing or closing the browser tab, let us update our store to look like this:

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {         user: null     },     mutations: {         SET_USER(state, user) {             state.user = user         }     },     actions: {         getUser({ commit }, userInfo) {             commit('SET_USER', userInfo)         }     },     plugins: [createPersistedState()] })

Here, we add a user state that would store user data from the form created in the previous section. We also add a SET_USER mutation that would be used in modifying the user state. Finally, we add a getUser action that would receive the user object and pass it to the SET_USER mutation property. The next would be to dispatch this action after validating our form successfully. This looks like this:

methods: {     login() {       this.submitted = true;       let invalidForm = this.$  v.form.$  invalid;       let form = this.form;       //check that every field in this form has been entered correctly.       if (!invalidForm) {         // process the form data         this.$  store.dispatch("getUser", form);       }     },   },

Now, if you correctly fill the form, submit it, and open the localStorage section in the applications tab in the devTools of your browser, you should see a vuex property that looks like this:

At this point, if you refresh your browser or open your app in a new tab, your user state would still persist across these tabs/session (on localStorage).

Conclusion

There are a lot of libraries that can be very useful in Vuejs web development and sometimes it can be hard to choose the one to use or where to find them. The following links contain libraries that you can use in your Vue.js application.

  1. vuejsexamples.com.
  2. madewithvuejs.com.

There is often more than one library that does the same thing that you’re trying to achieve in your application when searching for a ‘library’, the important thing is to make sure the option you settle for works for you and is being maintained by its creator(s) so it doesn’t cause your application to break.

Further Resources

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
19 Nov

Useful Tools In Vue.js Web Development

by TBSCategories: News

When working on a new project, there are certain features that are necessary depending on how the application is supposed to be used. For example, if you’ll be storing user-specific data, you’ll need to handle authentications, this will require the setting up of a form that needs to be validated. Things such as authentication and form validations are common; there are solutions that possibly fit your use case.

To properly utilize your development time, it is better you use what is available, instead of inventing yours.

As a new developer, there’s the possibility that you won’t be aware of all that the Vue ecosystem provides you. This article will help with that; it will cover certain useful tools that will aid you in building better Vue applications.

Note: There are alternatives to these libraries and this article is in no way placing these few over the others. They are just the ones I’ve worked with.

This tutorial is aimed at beginners that either just started learning about Vue or already have basic knowledge of Vue. All code snippets used in this tutorial can be found on my GitHub.

Vue-notification

During user interaction, there is often a need to display a success message, error message, or random info to the user. In this section, we’re going to look at how to display messages and warnings to your user using vue-notification. This package provides an interface with a nice animation/transition for displaying errors, general information, and success messages to your user across your application and it does not require a lot of configuration to get up and running.

Installation

You can install vue-notification in your project using either Yarn or NPM depending on the package manager for your project

Yarn
yarn add vue-notification
npm
npm install --save vue-notification

After the installation is complete, the next thing would be to add it to the entry point in your app, the main.js file.

main.js
//several lines of existing code in the file     import Notifications from 'vue-notification'     Vue.use(Notifications)

At this point, we only need to add the notifications component in the App.vue file before we can display notifications in our app. The reason why we’re adding this component to the App.vue file is to avoid repetition in our application because no matter the page the user is on in our app, components in App.vue (e.g the header & footer components) would always be available. This takes the pain of having to register the notification component in every file that we need to display a notification to the user.

App.vue
<template>   <div id="app">     <div id="nav">       <router-link to="/">Home</router-link> |       <router-link to="/about">Notifications</router-link>     </div>     <notifications group="demo"/>     <router-view />   </div> </template>

Here, we add one instance of this component which accepts a group prop which would be used in grouping the different types of notifications we have. This is because the notifications component accepts a number of props that dictate how the component behaves and we’re going to look at a few of these.

  1. group
    This prop is used to specify the different types of notifications you might have in your app. For instance, you might decide to use different styles and behavior depending on what purpose the notification is supposed to serve, form validation, API response, etc.
  2. type
    This prop accepts a value that serves as a ‘class name’ for each notification type we have in our application and examples can include success, error, and warn. If we use any one of these as a notification type, we can easily style the component by using this class format vue-notification + '.' + type, i.e .vue-notification.warn for warn, and so on.
  3. duration
    This prop specifies how long the notification component should appear before disappearing. It accepts a number as a value in ms and also accepts a negative number (-1) if you want it to remain on your user’s screen till they click on it.
  4. position
    This prop is used in setting the position you want notifications to appear from in your app. Some of the available options are top left, top right, top center, bottom right, bottom left, and bottom center.

We can add these props to our component in App.vue so it now looks like this;

<template>   <div id="app">     <div id="nav">       <router-link to="/">Home</router-link> |       <router-link to="/about">Notifications</router-link>     </div>     <notifications       :group="group"       :type="type"       :duration="duration"       :position="position"     />     <router-view />   </div> </template> <script>   export default {     data() {       return {         duration: -1,         group: "demo",         position: "top center",         type: "info",       };     },   }; </script> <style>   .vue-notification.info {     border-left: 0;     background-color: orange;   }   .vue-notification.success {     border-left: 0;     background-color: limegreen;   }   .vue-notification.error {     border-left: 0;     background-color: red;   } </style>

We also add styling for the different notification types that we would be using in our application. Note that other than group, we can pass each of the remaining props on the fly whenever we want to display a notification and it would still work accordingly. To display a notification in any of your Vue files, you can do the following.

vueFile.vue
this.$  notify({   group: "demo",   type: "error",   text: "This is an error notification", });

Here, we create a notification of type error under the group notification of demo. The property text accepts the message you want the notification to contain and in this case, the message is ‘This is an error notification’. This is what the notification would look like in your app.

You can find out the other available props and other ways to configure the notification on the official docs page.

Vuelidate

One of the most common elements used on the web are form elements (input[type='text'], input[type='email'], input[type='password'], and so on) and there is always a need to validate user input to make sure they’re sending the right data and/or using the right format in the input field. With Vuelidate, you can add validation to the forms in your Vue.js application, saving time and benefitting from the time put into this package. I had been hearing about Vuelidate for a while but I was a little reluctant to take a look at it because I thought it would be too complex which meant I was writing validations from scratch for most of the form fields in the apps I worked on.

When I eventually looked at the docs, I found out it was not difficult to get started with and I could validate my form fields in no time and move on to the next thing.

Installation

You can install Vuelidate using any of the following package managers.

Yarn
yarn add vuelidate
npm
npm install vuelidate --save

After installation, the next thing would be to add it to your app’s config in the main.js file so you can use it in your vue files.

import Vuelidate from 'vuelidate' Vue.use(Vuelidate)

Assuming you have a form that looks like this in your app;

vuelidate.vue
<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />     </div>     <input type="submit" value="LOGIN" class="input__button" />     <p class="confirmation__text" v-if="submitted">Form clicked</p>   </form> </template> <script>   export default {     data() {       return {         submitted: false,         form: {           email: null,           fullName: null,           age: null,           password: null,         },       };     },     methods: {       login() {         this.submitted = true;       },     },   }; </script>

Now to validate this type of form, you first need to decide on what type of validation you need for each form field. For instance, you can decide you need the minimum length of the fullName to be 10 and the minimum age to be 18.

Vuelidate comes with built-in validators that we only need to import it to use. We can also choose to validate the password field based on a particular format, e.g Password should contain at least a lower case letter, an upper case letter, and a special character. We can write our own little validator that does this and plug it into the list of Vuelidate’s plugin.

Let’s take it step by step.

Using Built-In Validators
<script>   import {     required,     minLength,     minValue,     email,   } from "vuelidate/lib/validators";   export default {     validations: {       form: {         email: {           email,           required,         },         fullName: {           minLength: minLength(10),           required,         },         age: {           required,           minValue: minValue(18),         },       },     },   }; </script>

Here, we import some validators that we need to properly validate our form. We also add a validations property where we define the validation rules for each form field that we want to validate.

At this point, if you inspect the devTools for your app, you should see something that looks like this;

The $ v computed property contains a number of methods that are useful in confirming the validity of our form but we’re only going to focus on a few of them:

  1. $ invalid
    To check if the form passes all validation.
  2. email
    To check that the value is a valid email address.
  3. minValue
    To check that the value of age passes the minValue check.
  4. minLength
    To verify the length of fullName.
  5. required
    To ensure all required fields are provided.

If you enter a value for age less than the minimum age set in the validation and check $ v.form.age.minValue, it would be set to false and this means the value in the input field doesn’t pass the minValue validation check.

Using Custom Validators

We also need to validate our password field and ensure it contains the required format but Vuelidate does not have a built-in validator that we can use to achieve this. We can write our own custom validator that does this using RegEx. This custom validator would look like this;

<script>   import {     required,     minLength,     minValue,     email,   } from "vuelidate/lib/validators";   export default {     validations: {       form: { //existing validator rules         password: {           required,           validPassword(password) {             let regExp = /^(?=.[0-9])(?=.[!@#$  %^&])(?=.[A-Z]+)[a-zA-Z0-9!@#$  %^&*]{6,}$  /;             return regExp.test(password);           },         },       },     },   }; </script>

Here, we create a custom validator that uses a Regex to check that the password contains the following;

  1. At least one uppercase letter;
  2. At least one lowercase letter;
  3. At least one special character;
  4. At least one number;
  5. Must have a minimum length of 6.

If you try to enter any password that doesn’t meet any of the requirements listed above, the validPassword would be set to false.

Now that we’re sure our validations are working, we have to display the appropriate error messages so the user knows why they can’t proceed. This would look like this:

<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.fullName.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.email.required">         This field is required       </p>       <p class="error__text" v-if="!$  v.form.email.email">         This email is invalid       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.age.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.password.required">         This field is required       </p>       <p class="error__text" v-else-if="!$  v.form.password.validPassword">         Password should contain at least a lower case letter, an upper case         letter, a number and a special character       </p>     </div>     <input type="submit" value="LOGIN" class="input__button" />   </form> </template>

Here, we add a paragraph that displays either a text telling the user that a field is required, an inputted value for email is not valid or that the password doesn’t contain the required characters. If we look at this in your browser, you would see the errors already appearing under each input field.

This is bad for user experience as the user is yet to interact with the form and as such the error texts should not be visible at least, till the user tries to submit the form. To fix this, we would add submitted to the condition required for the error texts to show and also switch the value of submitted to true when the user clicks on the submit button.

<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.fullName.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.email.required">         This field is required       </p>       <p class="error__text" v-if="submitted && !$  v.form.email.email">         This email is invalid       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.age.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.password.required">         This field is required       </p>       <p         class="error__text"         v-else-if="submitted && !$  v.form.password.validPassword"       >         Password should contain at least a lower case letter, an upper case         letter, a number and a special character       </p>     </div>     <input type="submit" value="LOGIN" class="input__button" />   </form> </template>

Now the error texts do not appear until the user clicks on the submit button and this is much better for the user. Each validation error would appear if the value inputted in the form does not satisfy the validation.

Finally, we would only want to process the user’s input when all validations on our form have passed and one way we can do this would be to use the $ invalid property on the form which is present in the $ v computed property. Let us take a look at how to do that:

methods: {       login() {         this.submitted = true;         let invalidForm = this.$  v.form.$  invalid;         //check that every field in this form has been entered correctly.         if (!invalidForm) {           // process the form data         }       },     },

Here, we’re checking to ensure that the form has been completely filled and filled correctly. If it returns false, that means the form is valid and we can process the data from the form but if it is true , it means that the form is still invalid and the user still needs to tend to some errors in the form. We can also use this property to disable or style the submit button depending on your preference.

Vuex-persistedstate

During development, there are instances where you would store data like a user’s info and token in your Vuex store. But your Vuex store data would not persist if your users try to refresh your app from the browser or enter a new route from the URL tab of your browser and the current state of your application gets lost with it. This causes the user to be redirected to the login page if the route is being protected with navigation guard which is abnormal behavior for your app to have. This can be fixed with vuex-persistedstate, let look at how.

Installation

You can install this plugin using any one of the two methods:

Yarn
yarn add vuex-persistedstate
npm
npm install --save vuex-persistedstate

After the installation process is complete, the next step would be to configure this plugin to be ready for use in your Vuex store.

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {},     mutations: {},     actions: {},     modules: {},     plugins: [createPersistedState()] })

At this point, all of our Vuex Store would be stored in localStorage (by default) but vuex-persistedstate comes with the option to use sessionStorage or cookies.

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {},     mutations: {},     actions: {},     modules: {},   // changes storage to sessionStorage     plugins: [createPersistedState({ storage: window.sessionStorage }); ] })

To confirm that our Store would persist after refreshing or closing the browser tab, let us update our store to look like this:

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {         user: null     },     mutations: {         SET_USER(state, user) {             state.user = user         }     },     actions: {         getUser({ commit }, userInfo) {             commit('SET_USER', userInfo)         }     },     plugins: [createPersistedState()] })

Here, we add a user state that would store user data from the form created in the previous section. We also add a SET_USER mutation that would be used in modifying the user state. Finally, we add a getUser action that would receive the user object and pass it to the SET_USER mutation property. The next would be to dispatch this action after validating our form successfully. This looks like this:

methods: {     login() {       this.submitted = true;       let invalidForm = this.$  v.form.$  invalid;       let form = this.form;       //check that every field in this form has been entered correctly.       if (!invalidForm) {         // process the form data         this.$  store.dispatch("getUser", form);       }     },   },

Now, if you correctly fill the form, submit it, and open the localStorage section in the applications tab in the devTools of your browser, you should see a vuex property that looks like this:

At this point, if you refresh your browser or open your app in a new tab, your user state would still persist across these tabs/session (on localStorage).

Conclusion

There are a lot of libraries that can be very useful in Vuejs web development and sometimes it can be hard to choose the one to use or where to find them. The following links contain libraries that you can use in your Vue.js application.

  1. vuejsexamples.com.
  2. madewithvuejs.com.

There is often more than one library that does the same thing that you’re trying to achieve in your application when searching for a ‘library’, the important thing is to make sure the option you settle for works for you and is being maintained by its creator(s) so it doesn’t cause your application to break.

Further Resources

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
18 Nov

Useful Tools In Vue.js Web Development

by TBSCategories: News

When working on a new project, there are certain features that are necessary depending on how the application is supposed to be used. For example, if you’ll be storing user-specific data, you’ll need to handle authentications, this will require the setting up of a form that needs to be validated. Things such as authentication and form validations are common; there are solutions that possibly fit your use case.

To properly utilize your development time, it is better you use what is available, instead of inventing yours.

As a new developer, there’s the possibility that you won’t be aware of all that the Vue ecosystem provides you. This article will help with that; it will cover certain useful tools that will aid you in building better Vue applications.

Note: There are alternatives to these libraries and this article is in no way placing these few over the others. They are just the ones I’ve worked with.

This tutorial is aimed at beginners that either just started learning about Vue or already have basic knowledge of Vue. All code snippets used in this tutorial can be found on my GitHub.

Vue-notification

During user interaction, there is often a need to display a success message, error message, or random info to the user. In this section, we’re going to look at how to display messages and warnings to your user using vue-notification. This package provides an interface with a nice animation/transition for displaying errors, general information, and success messages to your user across your application and it does not require a lot of configuration to get up and running.

Installation

You can install vue-notification in your project using either Yarn or NPM depending on the package manager for your project

Yarn
yarn add vue-notification
npm
npm install --save vue-notification

After the installation is complete, the next thing would be to add it to the entry point in your app, the main.js file.

main.js
//several lines of existing code in the file     import Notifications from 'vue-notification'     Vue.use(Notifications)

At this point, we only need to add the notifications component in the App.vue file before we can display notifications in our app. The reason why we’re adding this component to the App.vue file is to avoid repetition in our application because no matter the page the user is on in our app, components in App.vue (e.g the header & footer components) would always be available. This takes the pain of having to register the notification component in every file that we need to display a notification to the user.

App.vue
<template>   <div id="app">     <div id="nav">       <router-link to="/">Home</router-link> |       <router-link to="/about">Notifications</router-link>     </div>     <notifications group="demo"/>     <router-view />   </div> </template>

Here, we add one instance of this component which accepts a group prop which would be used in grouping the different types of notifications we have. This is because the notifications component accepts a number of props that dictate how the component behaves and we’re going to look at a few of these.

  1. group
    This prop is used to specify the different types of notifications you might have in your app. For instance, you might decide to use different styles and behavior depending on what purpose the notification is supposed to serve, form validation, API response, etc.
  2. type
    This prop accepts a value that serves as a ‘class name’ for each notification type we have in our application and examples can include success, error, and warn. If we use any one of these as a notification type, we can easily style the component by using this class format vue-notification + '.' + type, i.e .vue-notification.warn for warn, and so on.
  3. duration
    This prop specifies how long the notification component should appear before disappearing. It accepts a number as a value in ms and also accepts a negative number (-1) if you want it to remain on your user’s screen till they click on it.
  4. position
    This prop is used in setting the position you want notifications to appear from in your app. Some of the available options are top left, top right, top center, bottom right, bottom left, and bottom center.

We can add these props to our component in App.vue so it now looks like this;

<template>   <div id="app">     <div id="nav">       <router-link to="/">Home</router-link> |       <router-link to="/about">Notifications</router-link>     </div>     <notifications       :group="group"       :type="type"       :duration="duration"       :position="position"     />     <router-view />   </div> </template> <script>   export default {     data() {       return {         duration: -1,         group: "demo",         position: "top center",         type: "info",       };     },   }; </script> <style>   .vue-notification.info {     border-left: 0;     background-color: orange;   }   .vue-notification.success {     border-left: 0;     background-color: limegreen;   }   .vue-notification.error {     border-left: 0;     background-color: red;   } </style>

We also add styling for the different notification types that we would be using in our application. Note that other than group, we can pass each of the remaining props on the fly whenever we want to display a notification and it would still work accordingly. To display a notification in any of your Vue files, you can do the following.

vueFile.vue
this.$  notify({   group: "demo",   type: "error",   text: "This is an error notification", });

Here, we create a notification of type error under the group notification of demo. The property text accepts the message you want the notification to contain and in this case, the message is ‘This is an error notification’. This is what the notification would look like in your app.

You can find out the other available props and other ways to configure the notification on the official docs page.

Vuelidate

One of the most common elements used on the web are form elements (input[type='text'], input[type='email'], input[type='password'], and so on) and there is always a need to validate user input to make sure they’re sending the right data and/or using the right format in the input field. With Vuelidate, you can add validation to the forms in your Vue.js application, saving time and benefitting from the time put into this package. I had been hearing about Vuelidate for a while but I was a little reluctant to take a look at it because I thought it would be too complex which meant I was writing validations from scratch for most of the form fields in the apps I worked on.

When I eventually looked at the docs, I found out it was not difficult to get started with and I could validate my form fields in no time and move on to the next thing.

Installation

You can install Vuelidate using any of the following package managers.

Yarn
yarn add vuelidate
npm
npm install vuelidate --save

After installation, the next thing would be to add it to your app’s config in the main.js file so you can use it in your vue files.

import Vuelidate from 'vuelidate' Vue.use(Vuelidate)

Assuming you have a form that looks like this in your app;

vuelidate.vue
<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />     </div>     <input type="submit" value="LOGIN" class="input__button" />     <p class="confirmation__text" v-if="submitted">Form clicked</p>   </form> </template> <script>   export default {     data() {       return {         submitted: false,         form: {           email: null,           fullName: null,           age: null,           password: null,         },       };     },     methods: {       login() {         this.submitted = true;       },     },   }; </script>

Now to validate this type of form, you first need to decide on what type of validation you need for each form field. For instance, you can decide you need the minimum length of the fullName to be 10 and the minimum age to be 18.

Vuelidate comes with built-in validators that we only need to import it to use. We can also choose to validate the password field based on a particular format, e.g Password should contain at least a lower case letter, an upper case letter, and a special character. We can write our own little validator that does this and plug it into the list of Vuelidate’s plugin.

Let’s take it step by step.

Using Built-In Validators
<script>   import {     required,     minLength,     minValue,     email,   } from "vuelidate/lib/validators";   export default {     validations: {       form: {         email: {           email,           required,         },         fullName: {           minLength: minLength(10),           required,         },         age: {           required,           minValue: minValue(18),         },       },     },   }; </script>

Here, we import some validators that we need to properly validate our form. We also add a validations property where we define the validation rules for each form field that we want to validate.

At this point, if you inspect the devTools for your app, you should see something that looks like this;

The $ v computed property contains a number of methods that are useful in confirming the validity of our form but we’re only going to focus on a few of them:

  1. $ invalid
    To check if the form passes all validation.
  2. email
    To check that the value is a valid email address.
  3. minValue
    To check that the value of age passes the minValue check.
  4. minLength
    To verify the length of fullName.
  5. required
    To ensure all required fields are provided.

If you enter a value for age less than the minimum age set in the validation and check $ v.form.age.minValue, it would be set to false and this means the value in the input field doesn’t pass the minValue validation check.

Using Custom Validators

We also need to validate our password field and ensure it contains the required format but Vuelidate does not have a built-in validator that we can use to achieve this. We can write our own custom validator that does this using RegEx. This custom validator would look like this;

<script>   import {     required,     minLength,     minValue,     email,   } from "vuelidate/lib/validators";   export default {     validations: {       form: { //existing validator rules         password: {           required,           validPassword(password) {             let regExp = /^(?=.[0-9])(?=.[!@#$  %^&])(?=.[A-Z]+)[a-zA-Z0-9!@#$  %^&*]{6,}$  /;             return regExp.test(password);           },         },       },     },   }; </script>

Here, we create a custom validator that uses a Regex to check that the password contains the following;

  1. At least one uppercase letter;
  2. At least one lowercase letter;
  3. At least one special character;
  4. At least one number;
  5. Must have a minimum length of 6.

If you try to enter any password that doesn’t meet any of the requirements listed above, the validPassword would be set to false.

Now that we’re sure our validations are working, we have to display the appropriate error messages so the user knows why they can’t proceed. This would look like this:

<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.fullName.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.email.required">         This field is required       </p>       <p class="error__text" v-if="!$  v.form.email.email">         This email is invalid       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.age.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />       <p class="error__text" v-if="!$  v.form.password.required">         This field is required       </p>       <p class="error__text" v-else-if="!$  v.form.password.validPassword">         Password should contain at least a lower case letter, an upper case         letter, a number and a special character       </p>     </div>     <input type="submit" value="LOGIN" class="input__button" />   </form> </template>

Here, we add a paragraph that displays either a text telling the user that a field is required, an inputted value for email is not valid or that the password doesn’t contain the required characters. If we look at this in your browser, you would see the errors already appearing under each input field.

This is bad for user experience as the user is yet to interact with the form and as such the error texts should not be visible at least, till the user tries to submit the form. To fix this, we would add submitted to the condition required for the error texts to show and also switch the value of submitted to true when the user clicks on the submit button.

<template>   <form @submit.prevent="login" class="form">     <div class="input__container">       <label for="fullName" class="input__label">Full Name</label>       <input         type="text"         name="fullName"         id="fullName"         v-model="form.fullName"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.fullName.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Email</label>       <input         type="email"         name="email"         id="email"         v-model="form.email"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.email.required">         This field is required       </p>       <p class="error__text" v-if="submitted && !$  v.form.email.email">         This email is invalid       </p>     </div>     <div class="input__container">       <label for="email" class="input__label">Age</label>       <input         type="number"         name="age"         id="age"         v-model="form.age"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.age.required">         This field is required       </p>     </div>     <div class="input__container">       <label for="password" class="input__label">Password</label>       <input         type="password"         name="password"         id="password"         v-model="form.password"         class="input__field"       />       <p class="error__text" v-if="submitted && !$  v.form.password.required">         This field is required       </p>       <p         class="error__text"         v-else-if="submitted && !$  v.form.password.validPassword"       >         Password should contain at least a lower case letter, an upper case         letter, a number and a special character       </p>     </div>     <input type="submit" value="LOGIN" class="input__button" />   </form> </template>

Now the error texts do not appear until the user clicks on the submit button and this is much better for the user. Each validation error would appear if the value inputted in the form does not satisfy the validation.

Finally, we would only want to process the user’s input when all validations on our form have passed and one way we can do this would be to use the $ invalid property on the form which is present in the $ v computed property. Let us take a look at how to do that:

methods: {       login() {         this.submitted = true;         let invalidForm = this.$  v.form.$  invalid;         //check that every field in this form has been entered correctly.         if (!invalidForm) {           // process the form data         }       },     },

Here, we’re checking to ensure that the form has been completely filled and filled correctly. If it returns false, that means the form is valid and we can process the data from the form but if it is true , it means that the form is still invalid and the user still needs to tend to some errors in the form. We can also use this property to disable or style the submit button depending on your preference.

Vuex-persistedstate

During development, there are instances where you would store data like a user’s info and token in your Vuex store. But your Vuex store data would not persist if your users try to refresh your app from the browser or enter a new route from the URL tab of your browser and the current state of your application gets lost with it. This causes the user to be redirected to the login page if the route is being protected with navigation guard which is abnormal behavior for your app to have. This can be fixed with vuex-persistedstate, let look at how.

Installation

You can install this plugin using any one of the two methods:

Yarn
yarn add vuex-persistedstate
npm
npm install --save vuex-persistedstate

After the installation process is complete, the next step would be to configure this plugin to be ready for use in your Vuex store.

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {},     mutations: {},     actions: {},     modules: {},     plugins: [createPersistedState()] })

At this point, all of our Vuex Store would be stored in localStorage (by default) but vuex-persistedstate comes with the option to use sessionStorage or cookies.

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {},     mutations: {},     actions: {},     modules: {},   // changes storage to sessionStorage     plugins: [createPersistedState({ storage: window.sessionStorage }); ] })

To confirm that our Store would persist after refreshing or closing the browser tab, let us update our store to look like this:

import Vue from 'vue' import Vuex from 'vuex' import createPersistedState from "vuex-persistedstate"; Vue.use(Vuex) export default new Vuex.Store({     state: {         user: null     },     mutations: {         SET_USER(state, user) {             state.user = user         }     },     actions: {         getUser({ commit }, userInfo) {             commit('SET_USER', userInfo)         }     },     plugins: [createPersistedState()] })

Here, we add a user state that would store user data from the form created in the previous section. We also add a SET_USER mutation that would be used in modifying the user state. Finally, we add a getUser action that would receive the user object and pass it to the SET_USER mutation property. The next would be to dispatch this action after validating our form successfully. This looks like this:

methods: {     login() {       this.submitted = true;       let invalidForm = this.$  v.form.$  invalid;       let form = this.form;       //check that every field in this form has been entered correctly.       if (!invalidForm) {         // process the form data         this.$  store.dispatch("getUser", form);       }     },   },

Now, if you correctly fill the form, submit it, and open the localStorage section in the applications tab in the devTools of your browser, you should see a vuex property that looks like this:

At this point, if you refresh your browser or open your app in a new tab, your user state would still persist across these tabs/session (on localStorage).

Conclusion

There are a lot of libraries that can be very useful in Vuejs web development and sometimes it can be hard to choose the one to use or where to find them. The following links contain libraries that you can use in your Vue.js application.

  1. vuejsexamples.com.
  2. madewithvuejs.com.

There is often more than one library that does the same thing that you’re trying to achieve in your application when searching for a ‘library’, the important thing is to make sure the option you settle for works for you and is being maintained by its creator(s) so it doesn’t cause your application to break.

Further Resources

Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts
×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us