If you're in the automotive industry, I imagine you're familiar with the JD Power survey results that are released each year, where drivers have the opportunity to share their experiences with their cars. One recurring theme in recent years has been that HMI interfaces in many automobiles have experienced usability issues. As an industry as a whole, we have substantial room for improving the in-car user experience, and after carefully examining various data points, we've identified a few usability problems that are common and reoccurring across the automotive industry. Here are the five most common pitfalls and ways to avoid them.
Pitfall 1: Poor Input (audio and touch)
Garbage in, garbage out. Even a solid user experience can only compensate so much when input quality is poor.
Let's first look at touch. Think back to the earliest touch screens, where the resolution was poor and there was a noticeable delay in response due to slow processing times. Imagine the same scenario behind the wheel of a car, when a driver needs to keep his or her eyes on the road. Some solutions are straightforward, but for touch, a high quality screen with fine-grained touch resolution and a powerful central processing unit (CPU) reduces latency.
Audio quality is even more important for a system with voice recognition. Capturing what the user says incorrectly derails a satisfactory driver experience. If we go back to the JD Power results, we know that drivers have repeatedly complained that systems often don't understand what they say, and oftentimes drivers further complicate the experience by speaking too early, pausing for too long, and having other people interrupt them while speaking to the system.
All of these factors can play into a challenging audio signal, but a high quality microphone placed appropriately and addressing each vehicle model's unique acoustics can drastically elevate the driver's experience.
Natural Language Understanding (NLU) can help overcome many of the toughest challenges. NLU uses a statistical classifier to look at the sentence structure, word order, and other factors to make accurate guesses at the driver's intent. This makes it easier to get to the desired outcome even with missing or incorrect words from the driver.
The foundation of a good user experience
Despite the fact that this first pitfall seems quite obvious, we talk about it first for a reason: this is the foundation of a solid user experience. Even if we manage to avoid all four of the other pitfalls, the user experience will suffer if the quality of the input isn't properly addressed.
However, even with solid input, we still have a lot to do to prevent a poor user experience; bringing me to another pitfall that is affecting drivers behind the wheel.
Pitfall 2: Giving the users too much
If we overload the driver's attention, we're asking for trouble. Yet, this is something that continues to happen in cars on the road today. Systems are often designed for use in optimal conditions and don't account for the driver's already high cognitive load from the very act of driving, conversation with passengers, or pondering of what to pick up from the store after work. When drivers are given too much information in a single prompt or on the screen, it requires more attention and time to process causing a perilous situation. In a world full of distractions, we can't afford another one when it can be avoided.
Imagine if I was providing you the following driving directions:
...Turn right on Massachusetts Avenue and then follow it until you reach Harvard Square. When you get there, the road will split and you'll hang left but stay in the right lane so you can turn right immediately. Follow that road....
We know most in-car navigation systems don't provide that many turns in a single shot. And yet, we occasionally see this happen in other parts of the HMI. The problem happens when the system provides more than a couple of steps or pieces of information than the driver can remember at a given time, and understandably, the driver tunes it out or forgets some of it.
The worst? Help prompts. Some systems provide information on every domain supported, with a web address for a specific point of interest (POI) and a phone number to call for additional support. For example, in one car I recently evaluated, the help prompt was just over a minute long and I had to listen to it three times to get the piece of information that I really needed. I know the intentions of these systems are to provide a user with detailed information at any given time and save the driver from having to dig around for obscure information, but when prompts exceed a reasonable timeframe, it becomes counterproductive.
Luckily, this is fixable. We can make the systems conversational by incorporating NLU. Think about how we get help from another person – It's a two-way dialog that requires a lower cognitive load and feels more natural. This works best when help from the system is domain-specific rather than all encompassing. NLU plays an important role here since we often ask for help when we're unsure of something or confused. NLU works with a wide range of statements or requests that the driver may make before they've learned the best way to phrase something.
Visually, we risk falling into the same trap. If we ask a driver what information they want to know, we end up with a long list that includes everything from phone battery, to a map, to the album art for the current song. The driver's ability to glance at the screen is often compromised by too much information. A solution comes in the form of determining what drivers actually need to know at any given time and prioritizing that information.
The right amount of information
Presenting too little information is equally frustrating and dangerous as presenting too much. Not enough useful information and the driver may have to dig around for the necessary information, resulting in more distraction. It's a delicate balancing act, and one that should be done carefully.
We often fail to account for the multitude of events that the driver encounters. If we require more than the limited attention drivers can afford to give the infotainment system, we're setting ourselves up for failure. The existing challenge for our industry is to find the proper balance with just enough information to keep the driver in the loop, but hiding information that is superfluous.
Pitfall 3: Mismatched prompts and dialog
We risk introducing issues 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. Sometimes these problems 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 users need to think about how to respond, you've lost them. Likewise, if prompts are ambiguous and confusing; the interaction becomes less satisfying and more distracting.
Ensure dialog and interface designers are in sync – and test profusely. Testing doesn't always require real drivers (though this is ideal); however, you should use participants who are not in any way involved with designing or building the system.
Test well, test often
Frequent testing often provides surprising revelations. For example, research suggests that users prefer a prompt such as "How can I help you?" instead of "Please say a command". However, if we use "How can I help you?" in a limited system, we have used an open-ended prompt – we don't know if the user is going to ask for directions or try to order a pizza. If we can't support the types of responses that users may give, we can introduce more problems than we fix with the friendly prompt. Testing would catch this type of problem before the system makes it way to a driver.
Pitfall 4: Trying too hard to avoid errors
The JD Power IQS responses make it apparent that drivers are concerned and unsatisfied by infotainment system errors, especially since the error prompts often do not help drivers complete tasks. Good usability requires a system that is designed to prevent the user from making errors whenever possible, but that also gracefully handles them and is helpful when they do occur. It is this last part that is too often overlooked. In fact, some systems on the road today have taken that first part – avoiding errors – a step too far by trying to do something with every single voice command. If we do that, sure the driver may not get get an error. But is that such a good thing?
Consider why error messages can be a good thing. People learn through making mistakes, provided that they understand how they made a mistake, its implications, and that they know how to recover. IQS responses show this is not happening. Systems are not failing gracefully. A simple example of a graceful error can be found on nearly any user registration page to a website; when you miss a field, or enter values incorrectly, these pages turn those fields red and provide a hint to show you the proper formatting. They guide the user to the proper outcome.
Some of the cars on the road today will seem as though they understand what you're saying, yet they misinterpret and still execute a command, creating an extremely frustrating driving experience. The driver must be able to trust the system as both capable and competent. The driver cannot learn from mistakes this way.
Of course the first step is to try to prevent errors, but while not being afraid to throw an error if you need to. If you throw an error, make the error messages concise and helpful so that the driver learns how to complete his or her task next time.
Next, escalate the error prompts. Research shows that a three-step escalation strategy is ideal with domain-specific guidance (or top-level guidance if the user is not in a domain.) First, begin with a short error prompt that simply asks the driver to try again (e.g. "Pardon?"). Next, provide a longer prompt with more information that may help them change phrasing or behavior to move them toward task completion (e.g. "Sorry, I still didn't get that. Tell me the name of a point of interest or the address that you would like directions to."). Finally, if another error prompt is needed, throw the terminal error, giving the user enough information to start over and get through the task successfully (e.g. "Sorry, I'm still having trouble. Let's try this another way. I can help with getting directions to a point of interest, a contact name, or to an address. When you are ready, try asking for directions again.")
Robust, reasonable error handling
Don't take a good UX principle – preventing the user from getting errors where possible – too far, as you will lose user trust. Driver expectations are constantly increasing, and we need to continue to meet or exceed these expectations. Robust, helpful error handling will increase trust – and loyalty.
Pitfall 5: Assuming a shorter interaction is a better or safer interaction
It is easy to assume that the quicker an interaction, the safer and more satisfying the experience will be. This is one of the most misunderstood design concepts, and hence a big pitfall.
If we reduce prompt length too much, we find that users have to think really hard about the right way to say something. At best, they pause and the system times out. More likely, they take a guess at what they say, and if it's not right, they go through a series of errors that may also be too short to be helpful. This may inadvertently increase total interaction time, increase cognitive workload, and result in both a more dangerous and less satisfying interaction.
To be precise, imagine if a system's "Pardon?" prompt is 1 second long, and is encountered by a user 6 times before task completion. Imagine another system where a user hears the 1-second "Pardon?" prompt once, then a more helpful 10 second prompt that leads to task completion afterward. After accounting for the pauses between turns, the time it takes for a user to say something, etc. it's conceivable that the first user may have a very frustrating 30+ second task time, whereas the second may have a more pleasant 25 second task time. Five 1-second prompts don't necessarily mean shorter (or better) interaction than a single 5-second prompt.
This balance is achieved through making sure prompts are concise yet helpful. We should cut those ambiguous words that often introduce confusion and add little value. However, we shouldn't sacrifice naturalness of the dialog in doing so. Avoid trimming dialogs to the point of sounding machine-like. It is possible that more steps in an interaction can lead to reduced interaction time if it helps the user get through the interaction easily. Human interaction is complex; it isn't a zero-sum game.
If you ask drivers about what they want as they become more familiar with the system, they are quick to say they want to be able to interrupt the system and get through basic dialogs as quickly as possible. This should be accomplished with well-designed verbal barge-in, given that interrupting is a natural human behavior.
NLU once again is a valuable tool for avoiding this pitfall. A solid NLU model can make it possible for the driver to get through interactions with as little effort as possible.
Don't react to IQS scores by shortening prompts
Avoid the knee-jerk reaction to shorten prompts and interactions as much as possible in an attempt to reduce interaction time. The outcome may well be the opposite of the desired effect. Aim to make every interaction with these systems effortless, as opposed to speedy. This is especially important for new users and for expert users who get off track when focusing on driving instead of task completion.
Conclusion
These five pitfalls are clearly not exhaustive, but they are are some of the biggest problems we see in cars on the road today. As technology is rapidly moving ahead, we should be spending our time innovating and creating user experiences that our drivers don't even realize they want or depend on. But we can't do that if we can't first solidify the user experience at the most basic and common interactions.
Pitfall 1: Poor Input (audio and touch)
Garbage in, garbage out. Even a solid user experience can only compensate so much when input quality is poor.
Let's first look at touch. Think back to the earliest touch screens, where the resolution was poor and there was a noticeable delay in response due to slow processing times. Imagine the same scenario behind the wheel of a car, when a driver needs to keep his or her eyes on the road. Some solutions are straightforward, but for touch, a high quality screen with fine-grained touch resolution and a powerful central processing unit (CPU) reduces latency.
Audio quality is even more important for a system with voice recognition. Capturing what the user says incorrectly derails a satisfactory driver experience. If we go back to the JD Power results, we know that drivers have repeatedly complained that systems often don't understand what they say, and oftentimes drivers further complicate the experience by speaking too early, pausing for too long, and having other people interrupt them while speaking to the system.
All of these factors can play into a challenging audio signal, but a high quality microphone placed appropriately and addressing each vehicle model's unique acoustics can drastically elevate the driver's experience.
Natural Language Understanding (NLU) can help overcome many of the toughest challenges. NLU uses a statistical classifier to look at the sentence structure, word order, and other factors to make accurate guesses at the driver's intent. This makes it easier to get to the desired outcome even with missing or incorrect words from the driver.
The foundation of a good user experience
Despite the fact that this first pitfall seems quite obvious, we talk about it first for a reason: this is the foundation of a solid user experience. Even if we manage to avoid all four of the other pitfalls, the user experience will suffer if the quality of the input isn't properly addressed.
However, even with solid input, we still have a lot to do to prevent a poor user experience; bringing me to another pitfall that is affecting drivers behind the wheel.
Pitfall 2: Giving the users too much
If we overload the driver's attention, we're asking for trouble. Yet, this is something that continues to happen in cars on the road today. Systems are often designed for use in optimal conditions and don't account for the driver's already high cognitive load from the very act of driving, conversation with passengers, or pondering of what to pick up from the store after work. When drivers are given too much information in a single prompt or on the screen, it requires more attention and time to process causing a perilous situation. In a world full of distractions, we can't afford another one when it can be avoided.
Imagine if I was providing you the following driving directions:
...Turn right on Massachusetts Avenue and then follow it until you reach Harvard Square. When you get there, the road will split and you'll hang left but stay in the right lane so you can turn right immediately. Follow that road....
We know most in-car navigation systems don't provide that many turns in a single shot. And yet, we occasionally see this happen in other parts of the HMI. The problem happens when the system provides more than a couple of steps or pieces of information than the driver can remember at a given time, and understandably, the driver tunes it out or forgets some of it.
The worst? Help prompts. Some systems provide information on every domain supported, with a web address for a specific point of interest (POI) and a phone number to call for additional support. For example, in one car I recently evaluated, the help prompt was just over a minute long and I had to listen to it three times to get the piece of information that I really needed. I know the intentions of these systems are to provide a user with detailed information at any given time and save the driver from having to dig around for obscure information, but when prompts exceed a reasonable timeframe, it becomes counterproductive.
Luckily, this is fixable. We can make the systems conversational by incorporating NLU. Think about how we get help from another person – It's a two-way dialog that requires a lower cognitive load and feels more natural. This works best when help from the system is domain-specific rather than all encompassing. NLU plays an important role here since we often ask for help when we're unsure of something or confused. NLU works with a wide range of statements or requests that the driver may make before they've learned the best way to phrase something.
Visually, we risk falling into the same trap. If we ask a driver what information they want to know, we end up with a long list that includes everything from phone battery, to a map, to the album art for the current song. The driver's ability to glance at the screen is often compromised by too much information. A solution comes in the form of determining what drivers actually need to know at any given time and prioritizing that information.
The right amount of information
Presenting too little information is equally frustrating and dangerous as presenting too much. Not enough useful information and the driver may have to dig around for the necessary information, resulting in more distraction. It's a delicate balancing act, and one that should be done carefully.
We often fail to account for the multitude of events that the driver encounters. If we require more than the limited attention drivers can afford to give the infotainment system, we're setting ourselves up for failure. The existing challenge for our industry is to find the proper balance with just enough information to keep the driver in the loop, but hiding information that is superfluous.
Pitfall 3: Mismatched prompts and dialog
We risk introducing issues 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. Sometimes these problems 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 users need to think about how to respond, you've lost them. Likewise, if prompts are ambiguous and confusing; the interaction becomes less satisfying and more distracting.
Ensure dialog and interface designers are in sync – and test profusely. Testing doesn't always require real drivers (though this is ideal); however, you should use participants who are not in any way involved with designing or building the system.
Test well, test often
Frequent testing often provides surprising revelations. For example, research suggests that users prefer a prompt such as "How can I help you?" instead of "Please say a command". However, if we use "How can I help you?" in a limited system, we have used an open-ended prompt – we don't know if the user is going to ask for directions or try to order a pizza. If we can't support the types of responses that users may give, we can introduce more problems than we fix with the friendly prompt. Testing would catch this type of problem before the system makes it way to a driver.
Pitfall 4: Trying too hard to avoid errors
The JD Power IQS responses make it apparent that drivers are concerned and unsatisfied by infotainment system errors, especially since the error prompts often do not help drivers complete tasks. Good usability requires a system that is designed to prevent the user from making errors whenever possible, but that also gracefully handles them and is helpful when they do occur. It is this last part that is too often overlooked. In fact, some systems on the road today have taken that first part – avoiding errors – a step too far by trying to do something with every single voice command. If we do that, sure the driver may not get get an error. But is that such a good thing?
Consider why error messages can be a good thing. People learn through making mistakes, provided that they understand how they made a mistake, its implications, and that they know how to recover. IQS responses show this is not happening. Systems are not failing gracefully. A simple example of a graceful error can be found on nearly any user registration page to a website; when you miss a field, or enter values incorrectly, these pages turn those fields red and provide a hint to show you the proper formatting. They guide the user to the proper outcome.
Some of the cars on the road today will seem as though they understand what you're saying, yet they misinterpret and still execute a command, creating an extremely frustrating driving experience. The driver must be able to trust the system as both capable and competent. The driver cannot learn from mistakes this way.
Of course the first step is to try to prevent errors, but while not being afraid to throw an error if you need to. If you throw an error, make the error messages concise and helpful so that the driver learns how to complete his or her task next time.
Next, escalate the error prompts. Research shows that a three-step escalation strategy is ideal with domain-specific guidance (or top-level guidance if the user is not in a domain.) First, begin with a short error prompt that simply asks the driver to try again (e.g. "Pardon?"). Next, provide a longer prompt with more information that may help them change phrasing or behavior to move them toward task completion (e.g. "Sorry, I still didn't get that. Tell me the name of a point of interest or the address that you would like directions to."). Finally, if another error prompt is needed, throw the terminal error, giving the user enough information to start over and get through the task successfully (e.g. "Sorry, I'm still having trouble. Let's try this another way. I can help with getting directions to a point of interest, a contact name, or to an address. When you are ready, try asking for directions again.")
Robust, reasonable error handling
Don't take a good UX principle – preventing the user from getting errors where possible – too far, as you will lose user trust. Driver expectations are constantly increasing, and we need to continue to meet or exceed these expectations. Robust, helpful error handling will increase trust – and loyalty.
Pitfall 5: Assuming a shorter interaction is a better or safer interaction
It is easy to assume that the quicker an interaction, the safer and more satisfying the experience will be. This is one of the most misunderstood design concepts, and hence a big pitfall.
If we reduce prompt length too much, we find that users have to think really hard about the right way to say something. At best, they pause and the system times out. More likely, they take a guess at what they say, and if it's not right, they go through a series of errors that may also be too short to be helpful. This may inadvertently increase total interaction time, increase cognitive workload, and result in both a more dangerous and less satisfying interaction.
To be precise, imagine if a system's "Pardon?" prompt is 1 second long, and is encountered by a user 6 times before task completion. Imagine another system where a user hears the 1-second "Pardon?" prompt once, then a more helpful 10 second prompt that leads to task completion afterward. After accounting for the pauses between turns, the time it takes for a user to say something, etc. it's conceivable that the first user may have a very frustrating 30+ second task time, whereas the second may have a more pleasant 25 second task time. Five 1-second prompts don't necessarily mean shorter (or better) interaction than a single 5-second prompt.
This balance is achieved through making sure prompts are concise yet helpful. We should cut those ambiguous words that often introduce confusion and add little value. However, we shouldn't sacrifice naturalness of the dialog in doing so. Avoid trimming dialogs to the point of sounding machine-like. It is possible that more steps in an interaction can lead to reduced interaction time if it helps the user get through the interaction easily. Human interaction is complex; it isn't a zero-sum game.
If you ask drivers about what they want as they become more familiar with the system, they are quick to say they want to be able to interrupt the system and get through basic dialogs as quickly as possible. This should be accomplished with well-designed verbal barge-in, given that interrupting is a natural human behavior.
NLU once again is a valuable tool for avoiding this pitfall. A solid NLU model can make it possible for the driver to get through interactions with as little effort as possible.
Don't react to IQS scores by shortening prompts
Avoid the knee-jerk reaction to shorten prompts and interactions as much as possible in an attempt to reduce interaction time. The outcome may well be the opposite of the desired effect. Aim to make every interaction with these systems effortless, as opposed to speedy. This is especially important for new users and for expert users who get off track when focusing on driving instead of task completion.
Conclusion
These five pitfalls are clearly not exhaustive, but they are are some of the biggest problems we see in cars on the road today. As technology is rapidly moving ahead, we should be spending our time innovating and creating user experiences that our drivers don't even realize they want or depend on. But we can't do that if we can't first solidify the user experience at the most basic and common interactions.
Sign in to post
Please sign in to leave a comment.
Continue