In the second post in this series, I discussed how we tend to overload drivers with too much information through both visual and auditory channels. The intentions of these systems is to provide a user with any information at any given time to prevent the driver from engaging with the system and digging for additional information. But these systems provide too much information at times, with prompts that exceed 60 seconds at times or too much screen information about the phone, navigation, music, and more – all at the same time. Some systems feel like they forget that driving is the primary task, requiring more than the limited attention our drivers can afford to give the infotainment system. The challenge for our industry is to find this balance, with enough information to keep the driver in the loop, but hiding information that is superfluous.
So to recap – HMI design needs to avoid poor input quality and avoid providing too much information.
Another common pitfall is one that will limit how conversational our systems feel, introducing more usability problems.
Pitfall 3: Mismatched prompts and dialog
Have you ever had a conversation with another person and you feel like you’re talking about two completely different things? Maybe this has happened during a job interview where you realize the job wasn’t what you thought it would be. Or maybe this was a conversation with a toddler, or with a person who speaks another language and there’s difficulty communicating in a common language. You try to be understanding and find a way to make the conversation work, but after a point, it can become frustrating.
We risk introducing the same issue into our infotainment systems when our prompts and our dialog are not in sync. It often happens when we say something vague that could have multiple interpretations, but the system expects a specific response. Sometimes these examples are obvious. For example, some systems say things such as, “Is this number correct? Say ‘Dial’ or continue.” This prompt is asking the driver a yes/no question, and then instructing the driver to say Dial or to say more digits. However, to a novice user, it’s unclear how to proceed.
The solution here is relatively straightforward: keep the prompts in sync with the expected user responses. This is done by making the response and the entire dialog feel natural. If your users need to think about how they are supposed to respond, you’ve lost them. If the prompts are ambiguous, confusing the driver, the interaction becomes less satisfying and more distracting. Ensure the dialog and interface designers verify that these are in sync – and make sure you test, internally and externally. External testing isn’t necessarily using real drivers (though this is ideal), however, you should involve people who are not involved with designing or building the system. It often takes only a few users to identify points of confusion, and the fixes are often simple.
I wish this usability risk was limited to the more obvious examples, but alas, it’s not. It can extend to areas where following other best practices – having friendly prompts – can actually cause more issues if not done carefully. Our research indicates that users prefer a prompt such as “How can I help you?” to “Please say a command”. The preferred prompt is also open-ended: we don’t know if the user is going to ask for directions or try to order a pizza. “How can I help you” will be difficult to support properly if we don’t have a strong natural language understanding (NLU) model supporting our system. If we can only support a limited range of commands phrased in a specific manner (probably due to simple rule-based grammar), our prompts must only encourage a user to respond in a way we can support.
Here’s another pitfall that seems obvious on the surface (notice a theme?), but has intricacies that require consideration while designing and building these systems. In this case, the common trap can be avoided by ensuring that prompt wording encourages users to respond appropriately. We need to ensure that the wording is as natural as possible, reducing the cognitive load and preventing driver confusion. But importantly, we need to realize that if we aren’t able to build the ideal system, we remain aware of the limitations and account for this while creating these interactions.
In the next post, we’ll talk about the fourth pitfall: Trying too hard to avoid errors.