A personal operating system dashboard
Most of these are beautiful and most of them are lying to you by week three. The design is rarely the problem. The problem is that somebody has to keep the numbers on it true, and that somebody is you.
The one rule
A dashboard must be derived, never maintained. Every figure on it should be computed from the underlying project files at the moment you look, not typed into a status field that someone remembered to update. If any part of your dashboard can be edited directly, that part will eventually disagree with reality and you will have no way to tell which one is right.
This sounds like a technical detail. It is the whole thing. The reason people abandon these is almost never that the dashboard was ugly. It is that they stopped trusting it, and the moment you stop trusting a dashboard you stop opening it, and once you stop opening it there is no system.
Test any dashboard by asking where each number comes from. If the answer for a given tile is "I update that one myself", that tile is a liability, not a feature. Delete it or make it derived.
What actually belongs on it
| Panel | Answers | Derived from |
|---|---|---|
| What changed | What moved since I last looked, and where | File modification and the log line in each project |
| Waiting on me | What is blocked on a decision only I can make | Items marked as owned by you across every project file |
| Waiting on someone else | What I am owed, and how long it has been | Open commitments in the people files, with dates |
| Going quiet | What has not been touched in three weeks and should have been | Last-touched date per project, compared against its own cadence |
| This week | What is actually due | Dated items across projects and calendar |
Five panels. Notice that four of them are about attention rather than about status: what moved, what is stuck, what is owed, what is rotting. A dashboard's job is to point at the thing you would otherwise miss, not to reassure you that a list exists.
What does not belong
streaks and completion percentages feel productive, change nothing goal progress bars the number is guessed, so the bar is fiction habit grids a different tool's job, and a guilt machine anything you would type in see: the one rule a count of total notes vanity; nobody ever acted on it
The instinct when building one of these is to add. Every panel is a weekly cost and most of them pay nothing back. The version worth keeping is close to embarrassingly plain, which is a good sign rather than a bad one.
Why the derived rule is hard without help
Deriving a dashboard means something has to read every project file and roll it up on demand. In a workspace tool you do this with database views, which works and ties you to that tool, as covered in a personal operating system in Notion. In plain files you need something that reads the folder and computes the answer when you ask.
Which is what an assistant with file access does naturally. Ask for the status of everything and it reads the files and tells you, rather than showing you a page someone updated a fortnight ago. That also removes the second failure mode: the dashboard cannot go stale between refreshes, because there is no stored version of it to go stale.
Where it fits in the system
The dashboard is not a layer. It is a view over the structure, and it only works if the structure underneath is being kept current by something other than you, which is the build order in one sentence. The structure it reads from is at the template, the picture of how it all connects is at the diagram, and the recurring pass that produces most of the same answers is the weekly review.
A view you can trust because nobody types into it
The book builds the files, the assistant that keeps them true, and the derived views that read them. Every prompt printed, no code.
Get the bookSee a dashboard computed rather than maintained
Project status, commitments and what is going quiet, read off the underlying files on demand. Try the demo.
See the demo