Challenge
Speaking multiple languages seems simple, until you realize it's not. Could we find a simple way to save untold hours of maintenance and upkeep on regional bots?
Solution
A clear and simple tabular method to view, compare, and translate multiple bot responses that share the same conversational logic.
My Role
Lead/Senior product designer
Personal Takeaways
This project was the most ruthlessly scoped project I’d ever worked on up until that point in time. It was very interesting to strip away all the extraneous functionality until we arrived at a deceptively simple solution.
SITUATION
Customers had been asking for years for a way to make their Einstein Bots speak multiple languages, instead of having to build multiple bots which could each handle a single language.
Our bot building platform, Einstein Bots, was very powerful, but we’d never been able to crack the problem of speaking multiple languages. Some customers wanted to change their business logic for different regions, some customers wanted to keep the same logic, and still others wanted some way to have template or reference logic but with the ability to modify it where desired. It was a web of conflicting needs with no easy solution that could satisfy all of them. Thus, it stayed on the roadmap over the course of many releases without being tackled by the team.
PROJECT GOALS
Primarily we wanted to unblock customers who had more than a handful of regional bots (think on the order of 10+ bots, all speaking different languages and aimed at different countries in most cases). They were building bots that often shared a large portion of conversational flows (certainly a lot of transaction-based interactions), but would need to be rebuilt for new locales.
Maintenance and updates of these bots were often the more painful part of the process. Minor changes would need to be propagated across dozens of bots and then double- and triple-checked for accuracy. We wanted to minimize this ongoing effort.
DESIGN APPROACH
With those goals in mind, we still wanted to build as simple of a solution as we could. I explored two options at opposite ends of the complexity spectrum that we’d identified:
a full-featured design where users could maintain a library of templates that could be reused and either stay “linked” to the original (with changes propagated automatically), or that could be unlinked (in which case it was like being copy-pasted somewhere and wouldn’t be updated automatically)
a base-bones design where users could build a bot with all conversation flows once, and then update the text of responses (changing the language) without making modifications to the base conversation flow
I could see a use case for either of those, though the first solution was likely a case of overbuilding. But I wanted to show both directions to our users to see how they reacted.
PROTOTYPE + TESTING
I showed design prototypes during user research sessions to gauge the response and better understand the use cases for either approach.
Customers were interested and could see the benefits of both, but ultimately the positive feedback of the complex approach didn’t justify the added complexity for users and the significant added cost of build it.
We decided to build the simple, tabular approach, which was well-received even if functionally somewhat limiting.
LAUNCH + OUTCOMES
This was one of the most highly-anticipated releases of any of the Einstein products in the Salesforce Winter ‘22 release.
Details
URL: Release notes
Date: Nov 2022
Role: Senior product designer
Tools: Sketch