This is the first of a couple of articles about using product design approaches to create effective virtual assistant experiences, a method created for and first experimented at Bots in Live, a workshop that took place at Red Bull Basement in São Paulo, Brazil, in June 2019. The sequel to this article can be read here and our final product can be tested here.
When Red Bull Basement São Paulo invited me to conduct a workshop about artificial intelligence at their makerspace, I saw a great opportunity to unshroud some haze around this subject, even though for a small audience. My objective was to bust three common-sense myths about AI: the one that says that there is a magical entity called “machine learning” which can turn computers into sentient beings capable of learning all sort of things by themselves; the one that says that humanity isn’t ready (it never is, right?) to deal with conversational interfaces; and the one that says that chatbots are not yet on the right track to help humans solve some complex problems. And, of course, I would love to do so on a hands-on schema, with tangible results and a project based learning framework.
That’s right! I wanted my class to emerge from this 12-hour workshop — divided into two saturdays of 6 — with a little chattering bot to call their own.
I will not spend any line on the “what a chatbot is” part of the workshop, mostly because it does not add much to this specific debate. Neither will I mention my gorgeous PPT, capable of putting our Federal Attorneys to shame (non-Brazilians might catch the joke here). I want to go right to the hypothesis that I had in mind: that I could use some design thinking processes together with branding and creative writing to make ideas pop out like crazy and take form in the same rythm. I had with me seven extremely high-spirited and curious people, who were willing to make an incredible laboratory out of this. In the end, the workshop went live following three steps: purpose definition, semantic and narrative design and chat flow building.
That was the first question that was raised so we could start building something. I am quite aware that a bot without a clear and well-marked goal tend to drive itself towards nowhere. I have discussed these questions in another article, which I am about to translate, by the way. At the end of the day, our first premise was to direct our focus to a problem that we considered serious, that could be of public interest and that would be possible to treat with a conversational interface approach.
We spent some quality time discussing what kind of problem it could be (and, considering the total amount of time that we had, half an hour was huge part of it). We have discussed the possibility to create virtual assistants that would help citizens find urban recycling hubs; help citizens find urban points for throwing away electric waste; to better guide the user on how to use public transportation in steep neighbourhoods; to help find nearby cinemas or theatres… Until the moment that someone came up with the idea to create a bot to help people in vulnerability situations. Ok, but what kind of people? Suffering from what kind of vulnerability? Also: vulnerability or risk situations? Eureka: a chatbot to help, in some way, women suffering from domestic violence. The four women and three men who were attending the workshop, plus me and Denise, our hostess, saw there something daring and valuable. If done the right way, it could be, literally, a life-saver in a country so cruel and sexist as Brazil is. Having established a common-sense on what the logline of our purpose was, we were finally able to start design thinking our goal.
As an unconditional fan of Paulo Caroli’s Lean Inception method, could not avoid using his approaches to inspire myself while structuring a script for the workshop. Given our circumstances, I have decided to start straight ahead building an empathy map to help the class towards creating a consistent protopersona. That had plenty of value since, estabilishing a preliminar hypothesis of target audience, all of the voice tone, language and bot persona would became more intuitive. This was also one of the most extensive approaches, since we used a 7-step canvas model and spent about 5 minutes brainstorming each one of them, but the result was above satisfactory. In sum, what came out of this phase was this:
“Maria is a 40-year-old woman living in the poor suburbs of São Paulo who works with general services. She lives with people from different social backgrounds and has access to different information through different sources and channels. She is not an ignorant person, but she suffers a lot of abuse from her partner. She went to high school. She took a caregiver course in order to babysit rich people. As she works a lot, she has to leave her children in the public nursery in order to care of her boss’s children. Her husband is a taxi driver who is extremely misogynist and strongly believes in female inferiority.”
Maria does not really exists, but she inhabits many houses out there, from the periphery to the centres of big metropolises. Maria is no woman in particular, but she is many at the same time, living under the noses of so many people that is not able or does not want to see what is going on. The class understood that Maria, this anonymous which is so many, needed help. But how? With what?
The approach that we used to get to these answers above was a round of Is/Is Not/Does/Does Not to clarify some important concepts about the application we were about to develop. In which channel it would be published? What kind of features would it have? How it would communicate itself with many Marias, with so many different problems, scattered around so many different places out there?
We then decided to complement this approach was the elaboration of an Elevator Pitch that would be able to synthesise our product vision so far. This is a resource that I like very much, mostly because it presupposes a huge amount of information gathered in a few words. Therefore: choosing terms with strong meanings in order to bullseye the question in its sore point. The result that came out was something like this:
For women suffering from abuse, AjudaMaria (HelpMary) is a chatbot that is able to understand and offer information on how to overcome abusive situations in a safe and empathic way. Unlike public orientation guides, it offers information in a conversational real-time-based platform, and reveals alternative paths to police reporting.
This “alternative paths to police reporting” might seem a little controverse. I can explain this. One of the problematics raised by the female attendants of the workshop was the fear that some people have to transform their cases into police situations, due to uncountable possible reactions that might come from the aggressor. The lack of trust in the public institutions also was a point raised by the class. Countless women that raise these kind of reports are instantly labeled by the authorities as insane, hysterical, even liars. Many of them does not feel safe at their homes — imagine exposing their situations in a police department! It is not about being frivolous towards a serious matter, but being able to understand that the available devices may not be sufficient to solve this matter per se.
There was, of course, an obvious limitation in the tool that we were designing in a 12-hour workshop: we would not be able to create an official channel to send structured reports to public service having so little time. What we understood to be capable of was to create mechanisms to listen, understand and teach the person to find a solution more appropriate for her own case. And that, by itself, is a very complex task.
In order to overcome this inflection point, our next step was applying the Barbecue Approach to understand what was really essential for the product to work. Costs, guests and other complex tools of this dynamic weren’t considered: we focused on building a common understanding about what was our meat, our barbecue, our coal and our audience. And what could be stripped away from our “barbecue” that would not mischaracterize it as a barbecue.
The class defined, in a couple of minutes, that the bot would be a solid MVP as long as it would be capable of: asking some questions to understand what would be going on with the woman that it would be talking to; process the answers with natural language understanding and associating them with each type of aggressions mapped; indicate adequate channels for solving each issue; have the possibility to send follow-up messages after the first interaction; provide statistical data that would be able to alert all of the bot’s users about the severity of the “domestic violence” topic. These five features were the ones that the class considered the essential for the product to stand firm and act effectively on the basic problem, which was help a large amount of women, massively one-to-one speaking, in real-time interactions, on how to find the best way to overcome each and every situation that could come up.
It was a bold theory, but had background and sufficient consistency to become something solid. After the first six hours, I had before me a class with sparkling eyes, a well-defined purpose and two myths busted before them. Chatbots weren’t something out of this world anymore, and using them would seem so logic!
Now we were a leap away from the true hands-on, which was very well leaped on our next session, theme for my next article. For now, we stand thinking about the first great gain you need in order to build a chatbot effectively: get to know deeply the problem you want to solve, get to understand who is in need of help to solve it and what is the best way of doing so.
These might look like harmless questions, but they mean a lot!