You built a beautiful analytics dashboard. Charts, graphs, real-time updates. It's gorgeous.
Nobody opens it.
I know because I've done this exact thing — multiple times. And I've watched teams do it too. We pour effort into dashboards that become bookmarks we never click, tabs we close on Monday morning without looking at.
Here's what I've learned after shipping several developer tools: the best information delivery system is one you never have to open.
The Dashboard Problem
Dashboards require intent. You have to:
- Remember the dashboard exists
- Navigate to it
- Parse the information
- Decide what to do about it
That's four steps before you get any value. And every one of those steps is a place where you drop off.
Think about it — when was the last time you voluntarily opened your cloud provider's billing dashboard just to "check in"? Most of us only look when something goes wrong. The dashboard didn't prevent the problem. It just helped us understand the damage after the fact.
The Ambient Alternative
The tools I actually use daily share a pattern: they deliver information passively, right where I already am.
Your IDE's line count in the status bar. Git branch name in your terminal prompt. Battery percentage in your menu bar. You glance at these a hundred times a day without thinking about it. Zero intent required.
This is what I call ambient tooling — information that exists in your peripheral vision, costs zero cognitive overhead to consume, and only demands attention when something actually changes.
Why This Matters for Dev Tools
When I was building TokenBar, a menu bar tool that shows LLM token usage in real time, the original plan was a dashboard. A nice web UI with charts showing usage over time, cost breakdowns by model, the works.
Then I caught myself: I already don't open half the dashboards I have. Why would I open another one?
So instead, it sits in the macOS menu bar. One glance tells me what I've spent today. No tab to open, no login, no loading spinner. It's just there, like a speedometer.
The result? I actually look at my token spend now. Not because I'm disciplined — because the information requires zero effort to consume.
Designing for Glanceability
If you're building developer tools, here's the framework I use:
1. Put it where eyes already go. Menu bars, status bars, terminal prompts, editor gutters. Don't make people come to you.
2. Compress to one number. If your tool's primary value can't be expressed in one number or status indicator, you might be solving too many problems at once.
3. Escalate, don't broadcast. Show a calm green dot when things are fine. Flash red only when something needs attention. Most dashboards treat everything as equally important, which means nothing is.
4. Make deeper info optional. Let people drill down if they want, but don't require it for the core value.
The Attention Budget
Developers have a finite attention budget. Every time you pull someone out of flow to check a dashboard, you're spending that budget. Ambient tools respect it.
This applies beyond developer tools, too. I track my nutrition with a photo-based app instead of manually logging every meal. Same principle — reduce friction until the behavior is effortless, or it doesn't happen at all.
Build Tools That Disappear
The best tools don't feel like tools. They feel like extensions of your awareness. They work in the background, surface what matters, and stay out of the way otherwise.
Next time you're designing a developer tool, ask yourself: would I actually open this every day? If the answer is "probably not," skip the dashboard. Put the number in the menu bar.
Your users will thank you by actually using the thing.
I build small, focused Mac utilities. TokenBar tracks LLM token spend from your menu bar. Monk Mode blocks distracting feeds without blocking entire apps. Both designed to disappear into your workflow.
Top comments (0)