Short stories in Digital assistant design
Guest Contribution
Just sharing a few short stories from some experiences I’ve had when designing for chat and text bots something’s worked some didn’t.
Feel free to challenge or add to.
ALLOW USERS TO LEARN
On first encountering a bot we had great results when we let the user know what they can do by giving them some example utterances or text questions. We chose the examples wisely as you’ll find you may not be able to list them all so it’s important to establish the possible commands as well as intonate the probable as well.
Once the users have used the basic commands on the more common user journeys we successfully introduce commands for tasks and journeys hadn’t used yet. We did install a command glossary on the command “Help me” for both text and chat bots but anaclitic logs and testing showed that users preferred to experiment then abandon rather than read or hear a list.
HELLO WORLD
Beginning a conversation from a cold start i.e. without context, I found to be a challenging task as it branched out in too many conversation paths. It was easer for Bots to set the context if they initiate the conversation or set it quickly after activation.
SHOW ME
We found users wanted proof of important tasks they have completed.With text bots, we found that saving the text conversation in a history section worked well with users, not only did they have proof of a task they could relive the context the task was executed in.
With chat bots, we found that informing the user a receipt/transaction record would be sent to the user’s registered e-mail account made users feel confident. This significantly established trust and confidence, we found that 95% of users would check the first confirmation message, 40% would check the second and only 5% would check further messages.
WHAT IS THE MEANING OF LIFE
Users like to mess with Bot’s plain and simple, so instead of trying to create a foolproof system turn this weakness into a strength, reply with witty answers, users will love it.
REMEMBER
Users tend to automatically have bad short term memory with digital assistants. They heavily depend on traditional screen-based formats for visual cues, task orientation and also to help them remember.
So our digital assistant tasks needed to be short, they need to use natural language to help orientation we found building strong mental models very helpful.
With text bots there is a certain amount a user will scroll back up to jog there memory it’s helpful but not ideal, two scroll actions seamed to be most of our users limit before pausing for thought.
Chat bots suffer more from this so you might want to consider a recap in after completing a task and building in narratives.
i.e. “Which account would you like to transfer the 30 pounds from your current account to: your Savings account or your Holiday account?”
We consider a recovery route like the word “Back” taking the user to the beginning of a conversation branch or “Home/Start again” to restart the experience, but these were often forgotten about or not used much.
DEBUG BIND SPOT
So nothing in life is perfect and bugs are of course a part of our world. An insight we made when testing interactive prototypes is that users didn’t seam to register bugs in the normal way.
Sure the experience crashed on them and they would first stare in to space for a while, next try and retrace their steps, then abandon the task feeling as if it was their fault, some didn’t even mark the experience down.
With a newer and/or unfamiliar technology people are still learning their conventions and don’t really know what to expect and the fact that the new technology might be wrong didn’t really register with our testers.
The fact there wasn’t an visual re-enforcement via error message or obvious way to report bugs were the key drivers in this bug blind spot.
READ THE MANUAL
The coders manual that is. Chat bot development is happening fast, and designers need to fully understand the strengths and weaknesses of chat-bots I’m not preaching the ideal here but pointing out a really helpful way of overcome design challenges.
Case in point. We used a really great app called Sayspring, it was wonderful, we could mock up and run Alexa based designs without touching code, but when I started to play with the real Alexa Skills Kit (ASK) there was a world of untouched potential our design wasn’t making use of.
Example: In Sayspring we might have to ask multiple individual questions to find out which colour shape our user preferred, “Do you prefer the red star or the blue star?”, “Do you prefer the red sphere or the blue sphere?” etc.
In ASK we found we found a new development could identify multiple “utterances” (preferred colour and object variables) in that allowed us to ask one smart question and deal with a complex answer.
Powered by WPeMatico
