For most of last year I had two applications I had built for myself. One was a file-management tool I called the File-Tracker. The other was a project-overview dashboard I called Mission Control. Both ran locally on my desk. Both were technically functional. Both appeared in my workflow with equal frequency in my mental model.
In actual practice, I opened File-Tracker many times a day. I opened Mission Control approximately never. After the first week or two, it sat on my second monitor as a visually impressive screen I rarely looked at and never operated.
The puzzle this presents: I had built both. I knew what they did. I had designed them with care. They lived equally close to my hands. And yet only one of them stuck.
When I asked Claude to help me consolidate them — fold Mission Control's salvageable features into File-Tracker, retire the rest — the first move was diagnostic. Not how do we merge these? but why does one earn daily use and the other doesn't? Within a few exchanges Claude had named something I had felt for months but never articulated.
The categorical distinction
The File-Tracker is a working tool. It answers questions I have during the work. When I'm trying to find a document from a project eighteen months back, the File-Tracker is the surface I touch to find it. The work I'm doing — drafting a chapter, assembling a brief, finding a specific quotation — lives there. I open it because the work lives there.
Mission Control is a status dashboard. It summarizes the state of all my projects: file counts, last-modified dates, recent activity, milestones, links to project resources. Each of those summaries is true and accurate. But none of them answers a question I have during the work. The information Mission Control surfaces is downstream of the work I do in the File-Tracker, the websites I edit, the documents I write. By the time I see a summary, I already know it; I produced the inputs.
The categorical distinction: working tools earn daily use because doing the work requires the tool. Status dashboards do not earn daily use, because the status is downstream of the work, and you already know the status if you're doing the work. This is true even when the dashboard is well-designed and the working tool is mediocre.
Where this generalizes
The principle extends beyond personal tools. Most of the productivity tools being built today are status dashboards. Project-management dashboards that show task lists rolled up by team. Executive summary screens that aggregate metrics. End-of-year retrospectives that visualize your year. Each of these has the same property as Mission Control: it summarizes information that is downstream of the work, to people who already know what it shows because they did the work.
The tools that survive in real workflows are working tools. Text editors, email clients, calendars, code repositories, design canvases, the inbox. The kitchen knife. These are surfaces that produce or transform something. You use them because the production or transformation is the work; without them, the work doesn't happen. They earn daily use whether or not anyone summarizes them.
The line between the two categories is not perfectly clean, and it would be lazy to pretend otherwise. Some screens blur the categories productively. A trading floor's market-data display is a status dashboard, but the trader's work is reading the dashboard and acting on it; the work and the status are tightly coupled. An ICU monitor displays patient vitals — pure status — but the nurse's work is reading the monitor and intervening. Air traffic control is dashboard-shaped, but controllers are doing real work against it. In these cases the dashboard is the working tool, because the status changes faster than the human can act, and reading-and-deciding is the job.
For most knowledge work, this is not the case. The status doesn't change between glances. The information on the dashboard was produced by the same person looking at it. The dashboard is decorative.
Why builders keep making status dashboards anyway
Status dashboards are easier to build than working tools. A working tool requires understanding the work — the actual operations, the friction points, the questions people have at specific moments. A status dashboard requires only the data. You query the source systems, aggregate, visualize, ship. The person looking at it doesn't need to ask does this help me do my work? because the dashboard isn't trying to.
Status dashboards also satisfy a managerial impulse to see how things are going. They produce a kind of visibility that feels like control. For organizations, this is sometimes legitimate — managers genuinely need to see status to allocate resources or intervene. But for individual knowledge workers, the impulse is misplaced. You don't need to see how your own work is going. You're doing it.
The mistake I made with Mission Control was building one for myself. I had picked up the pattern from organizational software — the project-card grid, the milestones, the recent-files lists — and applied it to my personal situation, where it didn't fit. I didn't need a dashboard about my own projects. I knew how my projects were going. I had been working on them all morning.
The design implication
When designing a tool for daily use, the first question is: does using this tool do something, or does it just show something?
If using it does something — produces a file, sends a message, captures a thought, navigates to a needed resource — it has a chance of earning daily use. If it just shows something, it probably won't.
The corollary, when something is showing rather than doing, is to ask: what working tool is downstream of this status? Is there a way to improve the working tool such that the status becomes self-evident? Mission Control showed me file counts per project. The right move was not to make Mission Control's display of file counts prettier; it was to put the file counts directly inside the File-Tracker, where the work already happens. Subsume the dashboard into the tool.
This is what we did. Mission Control's project-card pattern became a tab inside the File-Tracker. The tab is functional in the way the standalone dashboard wasn't, because the project cards are now click-through to the file work itself. They are not just showing me file counts; they are a navigation surface into the actual files I am about to operate on. The dashboard became part of the working tool, and in doing so, became something I would use.
The partnership move
This piece of design is the kind of thing the partnership produces that I would not have produced alone. I had felt the asymmetry between the two tools — that one stuck and one didn't — for months. I had not articulated it. Without the articulation, I would have eventually built a slightly nicer Mission Control, or added more features to it in the hope that one would make it sticky. The diagnostic — working tools versus status dashboards — let me see that the problem was categorical, not incremental. There was no version of Mission Control I could have built that would have worked, because the category was wrong.
Claude could not have produced this insight without my data: the months of behavioral evidence that I opened one and not the other. I could not have produced it without Claude's structural patience to ask the diagnostic question rather than jumping to let's merge them. Together it took twenty minutes. Alone it would have taken me years, if I had ever gotten there.
Closing
Most of what gets called productivity tooling is status dashboards. The category fails for the same reason Mission Control failed: it shows information downstream of the work, to people who already know the information because they did the work. The category persists because it's easier to build than working tools and because it satisfies a desire to see things rather than do them. But it doesn't earn daily use, and tools that don't earn daily use don't accumulate the gradual improvements that come from being used.
If you're building a tool for yourself, the test is simple: do you reach for it, or do you check it? Tools you reach for, you keep. Tools you check, you abandon.