If you plan to add a feature or create a new product, there is one overall guideline that might make your efforts more useful. That is this:
Know who this feature or product is for.
What does that user want to do? How does your product support that user in solving their problem(s)? If you know who the product is for and the problem(s) they want to solve, it's easier to deliver a solution that will work.
But, sometimes, the user has a problem with your solution. The user does something that you do not expect. That's when you need to support that user.
Many vendors are now implementing chatbots so they can spend less money on support. I have no problem with that, as long as the chatbot can answer my question.
Consider the Support This User Needs
If you know who this feature or product is for, you might be able to anticipate the kinds of support the user needs.
I happen to like explainer text (primarily) and videos (secondarily) for the more complex aspects of the product. And give me a checklist so I can check what I did wrong when I get an error message. Chatbots are great at managing all of these.
But error messages need to mean something.
Today, I encountered a problem where a chatbot cannot help. I saw this error message: “App encountered a problem.”
This error message has zero information. What is the user supposed to do? Contact support. That increases your support costs.
Worse, that error message tells me I am not the person you designed this feature or product for. I should look for another product that is for me. Error messages always have two meanings: the error itself, and how the user feels when they see this error message.
Error Messages and Their Meanings
When I see a generic error message with zero information, I can be sure that someone thought:
- Our logic is sound. There is no way to get to that code. We don't need to be specific about the error because no one can get there.
- That user is not reasonable for trying to do that action. (That's where the user did something unexpected.)
- No one would ever want that circumstance, but we better catch it anyway. (That's where the user is “wrong.”)
While I can empathize with the vendor, all of these explanations blame the user. They show insufficient respect for the user. (I wonder if the team was under a ton of pressure to deliver.)
But users don't go directly to blame. Instead, they want information. Where should they get that information? What actions should they take next? Your precious chatbot that is supposed to save you customer support costs? It has no idea what to do.
What if you respected the user? The team could have used this as an error message: “Well, you should not have received that message. Sorry about that. Please send the log data and a screenshot. We'll get back to you shortly. Thanks for assisting us in making this a better product.”
Okay, maybe not so long. But this error message engages me as the ideal user for this product. I can be a better customer.
Help Users Be Better Customers for You
Based on their sales page, this vendor claims they built this feature or product for me. I am supposedly their ideal user.
Yet, I keep finding (and reporting) errors in this product. Too many of these error messages lack context or are generic. They do not engage me. Worse, these error messages make me wonder if I am the ideal user for this feature—or even this product.
Instead of useless error messages, consider how you can help this customer find a better solution.
Maybe you can see these customers' problems as an opportunity for you to build something for them. Or, maybe you can choose to help them find a different product and not have to support them. (That's exactly like helping a person who isn't right for your company find a job at a competitor. (See Helping People Move On and Practical Ways to Lead and Serve Others.)
If you know who your feature or product is for, you can finish the product because you know who you are developing for. That includes all the relevant documentation, error messages, and effective chatbot data.
Choose your ideal users. Develop and release for them. That will allow us users to be better customers and decrease your support costs.
Oh, not only is it true for a feature. It holds just as much when we talk about the whole products.
One of my favorite stories is when we went through the discovery workshop with a client of ours. The product idea was sitting somewhere between:
– professionals
– their customers
– distributors of the products the professionals used when serving their customers
It was only at the late stage of the discovery, when we finally managed to convince our client that, within his budget constraints, he cand have it all. And we got back to discussing who was the actual target customer?
The best part? It was neither of the trio.
It was, in fact, the manufacturer of the goods (which distributors distributed, and professional used when serving their clients).
No cards on the Miro board has changed. Suddenly, though, we all were looking at a very different product.
Pawel, thanks. Your experience mirrors mine. This is one of the (many) reasons I ask product leaders to never work alone. Yes, you used a discovery activity of some sort. (As a consultant, I often use a “call,” but I have also used initial deliverables.)
When the people who want to succeed discuss the problem(s), they often discover a whole constellation of issues no one considered alone. And products often need that kind of discovery more often than when the project starts.