Most utility alerts fail for a simple reason: they are technically correct, but they show up at the wrong moment.
I ran into this while building AirPod Guard, a small Mac menu bar app that warns when one AirPod is much lower than the other or did not charge before you leave for a call, commute, class, or workout.
The obvious implementation is easy:
- Read the left and right battery levels.
- Compare the two numbers.
- Show an alert when the gap is large.
That works as code. It does not automatically work as product design.
The alert has to match the user's intent
A low battery warning is only useful when the user is about to rely on the device.
If I am just sitting at my desk with AirPods in the case, I do not want nagging. If I am three minutes from a Zoom call and one bud is at 8%, I absolutely want the warning.
That changes the product rule from:
Tell me whenever the battery is uneven.
To:
Tell me when the uneven battery is about to cost me something.
That is a much better design target.
Exact numbers are less important than failure shape
For this kind of utility, a precise battery reading is not the whole story. The important pattern is asymmetry.
A pair at 80% and 74% is fine.
A pair at 91% and 9% is a problem.
The product does not need to explain every possible battery state. It needs to catch the shape users already complain about: one AirPod was not seated properly, the case contact was dirty, or one side silently failed to charge.
The copy matters because alerts are interruptions
Bad alert copy sounds like a system event:
Battery discrepancy detected.
Useful alert copy sounds like it understands the moment:
Left AirPod is at 9%. Charge it before your call.
Small difference, but it changes the feel from noise to help.
My rule now is: if an alert interrupts the user, the copy should say exactly why the interruption is worth it.
Default quiet beats default loud
Tiny Mac utilities live or die on trust. If a menu bar app cries wolf, people disable it or uninstall it.
So the safer product posture is:
- stay quiet most of the time
- surface the mismatch clearly when it matters
- make the threshold understandable
- avoid turning the app into another notification source
That is less flashy than a feature-heavy app, but it is usually what makes a utility feel native.
The bigger lesson
A good tiny utility is not just a script with a menu bar icon.
It is a narrow failure detector.
Pick one annoying failure. Detect it reliably. Interrupt only when the user would thank you for interrupting.
That is the bar I am using for AirPod Guard: catch the one-AirPod-dead-before-a-call problem before it ruins the call.
If you use AirPods on a Mac and have been burned by uneven charging, I built it here: https://airpodguard.com
Curious how other people think about alert thresholds in small utilities. Do you prefer strict settings, smart defaults, or both?
Top comments (0)