What building a presence-aware app taught me about productivity software
One thing surprised me while building my app:
A lot of productivity software assumes activity = attention.
No typing?
No mouse movement?
User must be away.
But after testing different approaches, I realized some of the most focused moments happen when people are doing almost nothing physically.
Reading
Thinking
Reviewing
Planning
Watching
Traditional activity signals miss a lot of that.
It also made me think differently about privacy and trust.
For example, some testers were actually more comfortable with local camera-based presence detection because it felt transparent with hardware indicators and clear permission prompts. Others felt audio processing was less invasive even when everything stayed on-device.
Same goal. Completely different trust reactions.
Curious if other builders here have run into similar situations where user behavior completely changed how you thought the product should work?
Replies
When there are no sales, that’s usually where the real product rethinking begins.
@julia_zakharova2 Yeah, I think that’s true.
No-sales or low-engagement periods force you to separate “features you were excited to build” from “things people actually value.” A lot of the assumptions I had early on sounded logical in theory, but real user behavior exposed the gaps pretty quickly.
Honestly, some of the most important product decisions came from moments where the original approach clearly wasn’t resonating the way I expected.
The camera vs audio finding is genuinely counterintuitive and I think it says something important about how people actually reason about trust.
It's not about what's technically more private. It's about what's legible. A camera with a hardware indicator is a clear contract. You see the light, you know exactly what's happening. Audio processing, even fully on-device, doesn't have an obvious signal, so the imagination fills in the gap with something worse.
I ran into a version of this building a financial analysis tool. Users were noticeably more comfortable with AI-generated conclusions when they could see exactly where the underlying numbers came from, a direct link back to the source filing. It wasn't that they trusted the AI more. It was that the mechanism was visible.
Your presence detection finding and this feel like the same thing - trust isn't really about privacy, it's about whether the user can see the contract clearly.
Did the testers who preferred camera-based detection engage differently with the rest of the product? Curious whether that trust posture extended beyond just the detection mechanism itself.
@willatsharpread That “legible contract” framing is honestly one of the best ways I’ve heard this explained.
The technical implementation mattered less than whether users felt they could clearly understand the boundaries of what the app was doing. The hardware indicator ended up acting almost like a trust anchor because it made the interaction visible instead of abstract.
Your AI analysis example feels very similar. I think users are often more comfortable with powerful systems when the mechanism is inspectable and understandable, even if the underlying tech is more complex.
And to your question, yeah, I actually noticed that users who were comfortable enabling presence detection tended to engage more confidently with the rest of the product too. Less hesitation, less second-guessing settings, more willingness to explore features. It felt less like “they trusted the camera” specifically and more like the initial trust posture carried into the broader experience.
As an end user, I would still prefer not to grant camera and/or mic permissions just because I cannot be 100% sure that the data won't leak (even if it originally wasn't supposed to - due to some bug, for instance). Probably being too paranoid, but... :)
@sk_uxpin I honestly don’t think that’s paranoid at all. That concern came up pretty consistently whenever I talked to people about permissions.
One thing I learned through this is that users are usually evaluating worst-case scenarios, not just intended behavior. Even if something is fully local and designed responsibly, people still think about bugs, exploits, future changes, or misuse later on.
That’s part of why I leaned heavily into keeping the behavior visible and predictable instead of trying to make it feel invisible in the background. I think users are much more comfortable when they feel like they can clearly see when something is active and understand exactly what’s happening.
@calvin_thurman that's a fair point, yet I couldn't completely get rid of my fear :)
Absolutely. I’ve noticed the same thing in productivity products: “activity” is often just the easiest thing to measure, but real attention can look completely passive from the outside.
Reading, planning, reviewing, or thinking can be some of the most focused moments, even with no visible input. The privacy point is also really interesting. Sometimes the solution that feels most trustworthy to users is not only the most technically private one, but the one that feels understandable, visible, and under their control.
Really thoughtful insight. đź‘Ź
@alpertayfurr Exactly.
I think a lot of software accidentally optimizes for what’s easiest to measure instead of what’s actually meaningful. Keyboard and mouse activity are convenient signals, but they’re not always accurate representations of focus or intent.
And I completely agree on the trust side too. One of the biggest surprises for me was realizing users often respond more positively to systems that feel understandable and observable, even if another approach is technically more private on paper.
That gap between technical reality and perceived trust ended up being a much bigger product consideration than I expected going in.