Writing · Infrared Project
Kill the dashboard
A dashboard is a confession. It says: we collected a lot of data, and we are leaving it to you to work out what to do about it.
Open any CRM and the first thing you see is a dashboard. Pipeline by stage. Activities this week. Conversion by source. Twelve tiles, nine colours, and somewhere in there, the one thing you actually need to do today.
Dashboards are not a design choice. They are what you build when the software cannot think and the person can. You make the data as legible as possible and hand it over. The person does the retrieval, the synthesis, the analysis and the decision, in their head, every morning, forever.
The agent reads the data now
That division of labour no longer holds. A model can read every thread in an inbox, every quote in a folder and every note in a record, and it can do the thing dashboards were always a substitute for: tell you what it means and what to do about it.
So we made a decision early that still surprises people. rubyDane has no dashboard. There is nothing to study. Ruby interfaces with all of the data, retrieves what matters, synthesises it into insights, turns those into recommendations, and hands them to you as actions you can take with your thumb.
Show outcomes and actions. Keep the KPIs for the agent.
What replaces it
Two things. The first is a stack. Every recommendation Ruby makes arrives as a card: who, why now, what she wrote, how sure she is. You act on the top of the stack and the next one is there. There is no view where you look at all of them at once and feel bad about the number.
The second is a conversation. When you want to know something, you ask. How did the week go. Who have we not spoken to in six months. Find me twenty roofing contractors in New Jersey and draft them something about the spring schedule. Ruby reads the real numbers, the real lists and the real inbox before she answers, and when the answer is a piece of work, she plans it and asks for your go-ahead.
Outcomes still exist, of course. Replies, meetings booked, revenue won. They show up on the home screen as a feed of what happened, because that is what an owner wants to know: what did she do for me today, and what came back. That is a different object from a KPI, which is a number you are responsible for moving.
Why this is harder than it looks
Removing the dashboard is easy. Earning the right to remove it is hard. If the agent is going to read the data for you, it has to be trustworthy about what it found, honest about what it does not know, and able to show its evidence when asked. Every draft Ruby writes carries her confidence score and the reason for it. Every recommendation to follow someone up carries the line from the thread that prompted it. You can always ask her why, and you can always open the thread she read.
That is what makes a dashboard safe to kill. Not that the data went away, but that something you can interrogate is reading it on your behalf.
On the go, by design
There is a quieter reason to kill the dashboard. Dashboards need a desk. A stack of cards and a chat fit in a pocket. The people we build for do not sit at a desk; they are on a site, in a van, between appointments. Software that only works at a desk is software that gets used on Sunday night, with resentment. Software that fits the thumb gets used at the red light, with a small sense of winning.