![Marian Harbach](https://web.dev/images/authors/marianharbach.jpg) Marian Harbach [X](https://twitter.com/HarbachMarian) ![Hengameh Rezaei](https://web.dev/images/authors/hengamehrezaei.jpg) Hengameh Rezaei [LinkedIn](https://www.linkedin.com/in/hengamehrezaei) ![Frederik Hermans](https://web.dev/images/authors/frederikhermans.png) Frederik Hermans [LinkedIn](https://www.linkedin.com/in/frederik-hermans) ![Thomas Steiner](https://web.dev/images/authors/thomassteiner.jpg) Thomas Steiner [GitHub](https://github.com/tomayac) [LinkedIn](https://www.linkedin.com/in/thomassteinerlinkedin) [Mastodon](https://toot.cafe/@tomayac) [Bluesky](https://bsky.app/profile/tomayac.com) [Homepage](https://blog.tomayac.com/)

<br />

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.

![Google Meet just before joining a meeting. The camera and microphone permission prompt is shown, and a separate dialog asks the user if they want to allow Meet to use the camera and the microphone.](https://web.dev/static/case-studies/google-meet-permissions-best-practices/meetpermission--beiqo5hrt9f.png)

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.

![The site settings dialog in Chrome open for the Meet app. It allows permissions to be reset.](https://web.dev/static/case-studies/google-meet-permissions-best-practices/meetpermission--qudihzztym.png)

## 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.

![A dialog in the Google Meet app asking the user if they want people to see and hear them in a meeting.](https://web.dev/static/case-studies/google-meet-permissions-best-practices/meetpermission--w9wkli7uep.png)

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.

![The Google Meet app in an ongoing meeting that the user has joined without allowing camera and microphone access. A button in the center offers the user the option to allow access to both.](https://web.dev/static/case-studies/google-meet-permissions-best-practices/meetpermission--weo23lfwpta.png)

## 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.