Bot Rot Set In? Design the Right Bot, Right – UX Collective

Requirements gathering for chatbots can use the Wizard of Oz UX technique. But are you sure those digital munchkins are on the yellow brick road to the job they’re hiring your chatbot for? (Poster seen in Dublin, Ireland)

One of the hopeful propositions for chatbots was their utter power of agency to increase mobile digital participation by reducing app fatigue. Ironically, I now believe we have reached the stage of chatbot fatigue.

Chatbots are the tech “game changer” du jour, except botification is being done just as badly as the wearable tech car crash we witnessed.

The wrong chatbots are being built, wrong. This article is about designing the right chatbot, right.

Been a Chatbot Game Chancer?

Yep, there’s now mega bot rot out there because of a dearth of design thinking about whether a new or existing task is worth botifying or not.

What is the core reason (80/20) that someone turns to your chatbot to do a job? What is the real MVP value of your chatbot’s functionality footprint? (Image from Product Camp Dublin 2018)

I have seen some woeful chatbots out there. There’s that barista training chatbot aimed at millennials that delivered a 50 page PDF manual in response to the utterance “how can I be a barista?”. Then there’s that running chatbot that advised me that my nearest Parkrun was 6,000 kilometres away, the assumption being that anyone asking was within a 300 kilometres radius of an Irish location. I was in San Francisco at the time, where there is a local run.

None of these chatbot arrivistes responsible for such poor solutions have asked: “Why is this person hiring my chatbot to do this job?”

The “User” and the Damage Done

First , that term “user” must go from the design of conversation UI solutions! User? WTF!

I detest that term “user”; only the usability business and illegal drug trade uses it. Let’s reclaim “user” as a real name in real life with a real job (paid or unpaid) to do. So, our “user” becomes a customer rep, a services technician, an event-goer, a mother, a parent, a patient, and so on.

But how do we find such people, especially if you’re a small startup or innovator? The answer is by looking out for them, being smart, getting out on the street, observing what real people are actually doing, while encouraging them to articulate reasons they might use a chatbot instead.

Job Profiling Persecution

Forget about the job profile approach to identify “users”.

Those unwieldy documents of job titles, descriptions, qualifications, experience, org chart position, motivations, IT expertise, and so on, are tl;dr defined. These tomes owe more to recruitment agencies and HR departments than to design and product management.

Profiles list many tasks that a role performs, not just the focussed critical 80/20 reason your conversational UI might really be a game changer and around which a killer solution can be built.

A job profile is not a real person. In the user experience business, it’s a statement for the prosecution of the mediocrity of design.

Don’t Take It Persona-ally, But…

Personas are next to go onto that “user” bonfire of the inanities.

Personas are stereotypical people, dumbed down versions of “a day in the life”, complete with stock photographs, typical responsibilities and tasks, personal characteristics, motivations, and tools.

Again, a persona is not a real digital adopter, but a distant idealisation, performing a non-prioritized list of tasks. These persona peeps may use many types of technology too; not good for innovation disruption by understanding why they might switch or integrate with your innovation.

There’s a reason the word “stereotype” usually comes with a negative connotation.

Get Close and Personal. Swipe Right for The Right Design

Instead, move closer to the customer, get up close and personal, and discover what they do.

How? Great design begins with a conversation.

Take a walk in their shoes. Try a little fun UX ethnography, guerrilla research, and the “Wizard of Oz” technique to identify that killer question or job that might inspire someone to continually turn to a conversational UI to actually do something.

Try a little fun UX ethnography, guerrilla research, and the “Wizard of Oz” technique to identify that killer question or job that might inspire someone to continually turn to a conversational or natural UI to actually do something.

Use a deep-listening, “tell me more about that”, approach.

Amazon, in the run up to the French launch of its Echo, for example, introduced Alexa to employees in its French fulfilment centres who interacted with the emergent voice assistant to help the voice chatbot learn French, cultural nuances and behaviours, and how to respond.

The launch of Amazon Echo in Spain and Italy will likely adopt a similar approach.

Research and design a chatbot that resonates emotionally and culturally, as well as functionally for your region. Check out Hofstede’s country comparison dimensions to help you shape that experience.

Fundamentally, focus on the person’s behaviour, and not on what they say or think they want. Watch their actions. Think of this as a Lean product management approach, a way to quickly design and build a chatbot to determine the certainty about its value. As Eric Ries says:

“The minimum viable product (MVP) is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

I encourage you to read Eric’s book, “The Lean Startup” and apply the thinking to chatbot product management and design.

What Chatbot Jobs Should You Design For?

Why do drivers of cars buy milkshakes at drive-in takeaways? There could be many reasons. By way of Harvard professor Clay Christensen’s (and others) Jobs To Be Done framework, it was found that people don’t buy and use things because they fit a persona or user profile.

Instead, people hire a service or product to do a job for them. In our milkshake example, the drink was hired because the drivers were bored and in danger of nodding off on a long journey.

So, use the Jobs To Be Done (JTBD) approach for designing the right chatbot, right!

The JTBD framework is focussed on understanding why someone hires a tool to do a job. Even in the gig economy. Image from a Dublin Area Rapid Transit (DART) train.

Read (or listen to the podcast) about Clay’s theory of disruptive innovation, and search on “JTBD” for more insight.

Think of it this way, as mentioned on the startup Intercom’s blog: JTBD allows you to focus on the essential product feature, and to generate a user story about why it’s needed. The story plot line structure for a product story, using the JTBD method, would be something like:

“When X happens, I want to Y, so I can Z.”

An example from the sales rep job world, might be:

“When new sales collateral comes online, I want an SMS on my phone, so I can take it on the road with me.”

Designing chatbots using the JTBD framework enables a template approach, listing the job to be done, the role, needs, and expected job outcome (we could add outcome performance goals in there too, but make that optional until you test).

Here’s a one page enterprise JTBD example you can turn into a template and use yourself:

A JTBD template completed for a mobile sales rep. You can use this template approach to frame the job to be done and as a way to shape a story about the job itself.

In our example, a sales rep on the road might want to hire a chatbot to enter new sales prospect details rapidly without using a special device, easily capture meeting locations and images of the opportunity, and share that data in SaaS for work later. She might want to do in 5 seconds. So, a voice-driven chatbot using smartphone out-of-the-box features such as the camera and GPS capability seems like a good opportunity for a chatbot solution.

Using the JTBD approach also helps shape and communicate the job story. A story untold is not a story. Phrase your job story well; using bullet points is fine. As John Dewey would put it:

“A problem well put is half solved.”

You can tell the JTBD story to customers, product managers, developers, investors, designers, actually to any stakeholder (although admittedly C-level management will probably just want to know what they’re getting as a return on investment for their budget spend).

Competition is Fierce, from Unexpected Quarters

Remember: There is competition with other tools for hiring your product or service.

In the case of our sales rep, she will still carry a notebook and pen — it helps recall — sticky/Post-it notes, an Apple iPad, a Windows laptop, and a Samsung smartphone, maybe.

This competition is at the job level, it’s not about the category the tool fits into. As Intercom points out, Microsoft Skype for example, addresses the same purpose as an airline seat booked for business travel — communicating with colleagues.

Chatbots compete against other tools and methodologies on the job hire level in many arenas — communicating, scheduling engagements, ordering, onboarding of employees, managing things to do, marketing, educating, entertaining, finding simple solutions and fixes — and must do so without special training, equipment, and so on.

But fundamentally, the JTDB approach really means the end of design as many people have come to think they know it. Design now becomes about the job the chatbot is being hired to perform by a human.

All tl;dr? OK, a Summary…

So, to design and build the right product right, remember these six simple points.

Build the Right Chatbot

  1. Use the JTBD framework: Why is this chatbot (or other product or service) being hired to do the job by this person? Watch their actual job behaviour, ask, and listen.

Build the Chatbot Right

2. Get to the MVP stage fast. Apply proven UI principles for chatbots such as creating prompts and messages with a conversational style, shape a personality, pick use cases based on speed, simplicity, pain alleviation, and that require no special device or training.

3. Have a clear primary job to be done. What is the 80/20 effort of the job? Avoid corner cases, nice-to-haves, and “what ifs?”.

Consider Microsoft Excel; a super-popular desktop spreadsheet and now service-offering, packed with features. But how much of that functionality do you use and how often? Probably 20% of the features or less to do 80% of the jobs you need Microsoft Excel for. There are other use case examples from the enterprise to get you thinking along those lines for chatbots.

4. Sketch and wireframe your chatbot solution first. Sketch can be with chatbots options, and now there are chatbot specific solutions for prototyping. All you really need to start is a pen, paper, and ideas.

Using wireframes means you can also apply familiar UX design patterns or chatbot design heuristics, making for productive development. Document any open questions, use an Agile backlog, and try collaborative, integrated cloud tools like Slack, or whatever suits your context of work, to agree your job sketch with stakeholders.

Botmock, one of a number of powerful prototyping tools for chatbots.

5. Use a conversational UI accelerator design kits and platforms with suitable backend AI and NLP capability to innovate fast. Use real conversation-toned text and scripts in your designs — in the language of the hirer — and iterate with the key stakeholders to agree on a chatbot solution before you code anything. Eliminate any surprises later!

Helloumi, a Spanish company specializing in conversational business and chatbots. APIs are at the core of a frictionless and natural experience for customers.

6. Don’t dribblise your design. With chatbots and conversational interactions stay true to the idea that no UI is the best UI of all. The UX design toolkit is now about API calls, AI, NLP, ML, integrations with services and regular device features (GPS, SMS, camera, and the microphone, for example). Platforms often provide any UI widgets if and when needed (for maps, attachments, avatars, and so on).

No UI is the best UI for a killer chatbot user experience.

Job Satisfaction? Better Test It!

Finally, do remember to test your innovation.

Chatbot heuristics and baked-in platform design can do some heavy lifting to prove your idea’s value, but for JTBD the most reliable testing of having solved a design problem are tests about real tasks by real people doing real jobs.

Plan to test your innovation before going live and after, and iterate if needed. Keep focussed on the JTBD. If that is wrong, then no amount of fancy visual UI design is going to fix it and provide differentiation for switching or adoption from another tool. As Seymour Chwast puts it:

“If you dig a hole and it’s in the wrong place, digging it deeper isn’t going to help.”

Remember, people are hiring your chatbot to do a job. Hiring. In the age of the cloud, it’s easy to switch chatbots, apps, and services because of the subscription model.

There’s competition for that apps, services, and chatbot job hire. Be competitive!

More Resources?

  • A great presentation on JTBD, Lean Startup UX, and Wireframing from Product Camp Dublin 2018 is available on Slideshare.
  • Watch out for ConverCon 2018 in Dublin, Ireland in September 2018 (previously reviewed), an event with chatbots at its heart. I might see you there to chat in person about the JTBD of your chatbot!

Ultan O’Broin (@ultan) is a digital transformation and user experience consultant working with startups and the STEAM community, specialising in conversational UI for SaaS. With over 20 years of product development and pre-sales design thinking outreach in Silicon Valley and Europe, he has written extensively on enterprise chatbot use cases, design, personality, and the globalization of conversational commerce.

All images and screen captures in this article are by Ultan O’Broin. Copyright or trademark ownership vested in any screen capture is acknowledged, where applicable.

Author: Ultan O'Broin

Collect by: