“Sorry I Was on Mute” — Why this Embarrassing Slip-up Might Not Be Our Fault
The COVID-19 pandemic has led to more of us relying on group video calls to spend time with others. Whether that’s meetings at work or lockdown quizzes with friends, video chat has become a bigger part of our lives since March 2020.
Among the many things that define living under lockdown, accidentally being on mute during a video call, is something that most of us can relate to. It even made its way into the 2020 New Year’s Eve celebration in London.
When it happens, it is something we joke about, something to remind others that we are human during a period when we are lacking human contact, but in this article, I want to examine why this happens and what could be done to mitigate it.
Why does this happen?
Initially, it feels entirely down to user error because muting/unmuting yourself is so easy to do — click a button. We blame ourselves and feel a bit silly because we know what we are supposed to do, but for some reason, we failed to do something that we feel is basic.
But this could be caused by the design of the application itself. Don Norman talks about this in his book The Design of Everyday Things.
In the book, he recalls visiting a large computer company to evaluate a brand-new product. When using the keyboard to enter data, pressing the “return” key would save it, but pressing “enter” would erase it. Both keys were quite close to each other on the keyboard and during the evaluation he would continuously press the wrong one, deleting precious data and forcing him to repeat work he has already done.
When explaining the problem to the Product Designer, his observations were immediately dismissed because nobody had mentioned this after months of use. They had reported other problems, but not this one.
On speaking to its users, he learned that this was a frequent problem — “We do that a lot.” When asked why they hadn’t reported it, they did not believe it to be a problem with the product, because they had been told what each key did and when they pressed the wrong one, they blamed themselves for making the mistake.
“Invariably people feel guilty and either try to hide the error or blame themselves for stupidity or clumsiness. Still, if the task appears simple or trivial, then people blame themselves.“ — Donald A. Norman, from The Design of Everyday Things
So, with the understanding that user error could be allowed to happen because of the application’s design, I want to explore what, if anything, could be causing this mute misunderstanding in some of the video chat apps we use.
Design review
Each video chat app follows the same convention — you click a button that has a microphone on it to mute or unmute yourself. When your mic is on you see the icon and when you’re on mute the icon has a line through it.
Even though each app follows the same convention, it is the convention itself which could be at fault. Here is what I think is going on.
A button, whether in the browser, a native app, or the physical world, exists to let you do one thing and is labelled with a clear, distinct action.
However, mute buttons are telling you the current state of your microphone, not the action.
In the example above, the button on the left is telling you that your microphone is on and the one on the right is telling you that you are on mute. The icon is indicating the opposite of the action that will happen when you click on the button.
I believe it has been designed this way to make it easy for us to see at-a-glance if our mic is on. However, it is also creates a conflict between the state and the action and sometimes we interpret it the wrong way.
So how do we fix this?
My initial thought was to separate the button’s action from the information that is telling us whether the mic is on. Have the button display the action and display the state of the mic alongside it:
This uses the microphone icon to display the current state, which we are already used to, and the label and proximity of the button makes it clear where to click to toggle the state. I realise that this takes up more room than the simple icon, but some more information is required to solve the problem.
While still feeling smug about this design, I joined a Teams meeting and spotted a far simpler solution, the toggle switch!
A toggle switch is a perfect way to let you control your microphone because it has two states (like a microphone), it is clear which state it is in, but also acts as the control for it, all without breaking any UI conventions. This means that as a designer you can (attempt to) solve the problem without taking up much more room in the UI.
Here is a crude example of how this would look in Microsoft Teams:
This is a minimal change that does not deviate too much from the current UI and as this component already exists elsewhere in the application, swapping it would be a quick way to know if it solves the problem. You could also go one further and use a toggle to turn your camera on and off, to make things consistent.
One other thing
When researching for this article, one common thing I heard from others was that Teams tells you when you are muted. This is true, and they are referring to this message that appears when it detects a sound while you are on mute:
This is helpful and goes some way to solving the problem, but as this only appears once you have already started talking, it is allowing you to make the error and it would be better if this problem did not happen at all. Jakob Nielsen talks about this in his 10 Heuristics for User Interface Design:
“Good error messages are important, but the best designs carefully prevent problems from occurring in the first place” — Jakob Nielsen
Conclusion
What feels like an embarrassing and slightly silly mistake might not be our fault. Teams, Zoom, Slack and other video chat apps are telling us the opposite of what the mute button will do by choosing to display the current state of the microphone instead.
This forces us to do some mental gymnastics to derive what is going on from the UI. Sometimes we see an action to mute our mic and believe that it is already on and sometimes we see the muted state and know to turn our mic on.
If we swap the button for a toggle, we can more effectively tell the user whether they are on mute and provide an equally simple method to turn our mic on or off. By adding this clarity, we reduce the cognitive workload (the work the user must do within the application) of the user and reduce the chances of making the mistake.
