Google Meet is a web-based video-conferencing app, which removes the need for a dedicated app on desktop operating systems. It's therefore critical that users are able to efficiently control access to their microphones and cameras using the web's permission model. The Meet team encountered challenges when their users did not initially allow permission access to their cameras and microphones, which later meant users had trouble when they tried to activate video and sound during their meetings. This case study describes how the Meet team improved permissions and the impact it had on users' meeting satisfaction.
Meet permissions UX before the improvement
Before the improvements were launched in mid 2023, a user joining a Meet call for the first time would encounter a dialog in the center of the screen as well as the browser's permission prompt in the upper left corner. In the worst case, if no other website was previously allowed camera and microphone access, these steps would be followed by another permission prompt from the host operating system to allow Chrome access to those devices.
Considering existing permission UX best practices, the Meet dialog did explain why Meet was asking for access. Yet, the dialog also didn't fulfill other best practices, by only having a "Dismiss" button and no direct relationship with the browser permission prompt. Additionally, both Meet's dialog as well as the browser prompt appeared immediately when the page loaded, which is usually after clicking a link to join a call. This unexpected barrage of popups on the screen likely overwhelmed some users.
In addition, user feedback suggested that users encountering this experience were afraid that allowing access at this stage would make them seen and heard to other meeting participants without being able to control this later on.
With this UX, some Meet users were confused and did not allow camera and microphone access when first prompted. Additionally, those who clicked the "Block" button in the permission prompt blocked access to camera and microphone for any future Meet call. It's likely that these users only wanted to block access temporarily and might want to revisit their decision for a future call, which is possible by ignoring the permission prompt or clicking the "x" button.
Unfortunately, getting out of the blocked state is not entirely straightforward. Users have to click the Site Settings icon in the address bar and toggle camera and microphone or click the Reset permissions button. While these settings can be hard to find and often need detailed instructions for users to locate, they're important to maintain to prevent spammy sites from abusing their power and pestering users until they accept.
Improvements
To improve the experience, the Meet team revisited their users' needs and identified that not everyone joining a meeting wanted or needed to allow camera and microphone access immediately. Some users might just want to listen in, at least initially, while others might want to explore the Meet UI to familiarize themselves with it before having a call in the future. Showing people the permission prompt in situations like these led to undesired outcomes for Meet (having to help users recover from a previous block decision later) and the user (having to deal with a permission prompt that was unnecessary for their needs at that moment).
To address these challenges, the team designed an improved version of their permission pre-prompt that is more in line with the permission UX best practices. The new design makes the following changes:
- It asks the user about their intention: whether they want to be seen and heard in the meeting. The UI now offers an explicit decision, with options for situations where the user wants to be seen and heard, and situations where that is not the case.
- Only after confirming that this is a context where microphone and camera access has value to the user does Meet show the permission prompt.
- The button for the affirmative decision says "Allow microphone and camera" to prepare the user for the permission prompt.
- The design is modal, clarifying that a decision is necessary before the call can be joined.
- The design reminds the user that this decision is just about the basic access and they can still turn off their microphone and camera whenever they want.
If the user clicks on "Allow microphone and camera", the browser permission prompt appears and the Meet dialog changes to provide instructions on what to do next ("Click Allow") based on the decision the user took on the previous screen. The reminder about being able to turn off the microphone and camera is reiterated to continue providing the user with some peace of mind in case they are worried about a lack of control during the call. Finally, Meet also highlighted that camera and microphone can still be added if the user initially decided to continue without microphone and camera.
Impact
Using this improved permissions user experience, the Google Meet team was able to increase the share of users who allow microphone and camera usage when first joining a call by 14%. Consequently, fewer users click "Block" in the permission prompt, getting into a state where extra steps are necessary to re-enable microphone and camera access in a future call.
Note that the increase in the share of users allowing access doesn't mean that many more users suddenly allowed access. Instead, Google Meet now shows fewer permission prompts to first-time users, given that users who don't want to use their camera or microphone can indicate that preference from the outset.
Conclusions
The key to success was to only show the permission prompt when Meet is reasonably sure that users are ready to allow access. The UI now asks a question that users can meaningfully answer while also getting reassurance about being able to control capability usage. This clearer UI design enabled Google Meet to reduce friction. Users now have higher success rates during their first use and showing less prompts led to less people blocking access, thus needing less help to access camera and microphone when they actually wanted to.
If your web application uses permissions, you should consider if you are asking for permission when you are reasonably certain that your users want to allow access, because they are ready to use that capability. If not, users might block the permission your application needs and will struggle to allow that access when they do need it.