Consent screens are designed to be clicked through. Is that a UX problem or a trust problem?
every app that uses OAuth shows you a consent screen.
here are the permissions this app is requesting. the list is there, the allow button is there, and almost nobody reads it before clicking.
this is by design, not by accident. the screens are built to be fast. the language is technical enough to feel legitimate but vague enough to not alarm anyone. 'access to your files' could mean one document or your entire drive and the screen won't tell you which.
the common response is that users should read more carefully.
but that argument falls apart pretty quickly. if every screen is designed to be clicked through, and every user clicks through, that's not a user behaviour problem. that's a design outcome.
the more interesting question is whether consent screens are actually about user understanding at all.
because if they were, they'd look very different.
you'd see plain language. you'd see specific examples.
you'd see a way to grant partial access rather than all or nothing.
what they're actually optimised for is legal coverage, not informed choice.
curious whether people think this is fixable at the UX level or whether the problem is structural.
and if you've seen a consent flow done well, genuinely curious what made it different.
Replies
Both, but the trust problem is upstream.
Concrete example from this week: I got an email from AdMob saying an upcoming SDK update will start collecting coarse location from apps that already have location permission. There's a config flag to opt out.
Here's the thing. That flag exists, it's documented, and I'd bet most developers adopting that SDK version won't know it's there. The consent the end user gave was for the app to use their location for a feature. Nobody asked them about ad targeting.
So by the time the screen reaches the user, the real decision was already made three layers up by someone who skimmed a changelog. Making the screen clearer wouldn't fix that.
The UX problem is real too, but it's downstream of the fact that consent is collected where it's cheapest to collect, not where the decision actually happens.
It’s primarily a structural problem consent screens are currently optimized for legal liability transfer rather than true user comprehension, making fast click-throughs a feature of the system rather than a bug. Fixes need to be contextual: deferring requests until a feature actually requires them and offering granular access (like Apple’s Select Photos model) rather than all or nothing buckets. Until regulations or platforms penalize vague scope bundling, UX will keep optimizing for speed over clarity.
ArchFormation
For calendar access, showing the exact event that a feature would read or change before asking permission seems more understandable than a broad scope label. Would asking at that moment help, or does the platform's permission screen still get in the way?