Stop ordering dashboards. Name the decision.
Define who can act, what they need to know, and when a report is enough before paying for another wall of charts.
“We need better visibility” can buy an impressive amount of software without settling what anyone should do differently.
A dashboard answers questions about a situation. Whether those answers justify action depends on something the charts cannot supply: a decision someone has the authority and time to make. Without that, a red indicator is just an expensive way to feel behind.
Before commissioning the screen, finish this sentence: “When this condition occurs, this role chooses between these actions before this deadline.”
If you cannot finish it, keep investigating. You may need a report, an exploratory analysis, or a conversation about who gets to decide. None of those becomes more useful because a vendor puts a dial on it.
Define the choice before the metric
Start with a recurring decision that currently requires people to assemble information by hand. Describe the available actions, including doing nothing. Identify what each action commits: money, capacity, a customer promise, or somebody else’s time.
Then list the facts that could change the choice. A metric belongs on the screen when it helps distinguish between actions or exposes a constraint. An impressive metric that changes nothing can go in the report appendix.
Ask what happens when the information is late or incomplete. “Live” is an unhelpful requirement until you specify how old a fact can be before it becomes unsafe to use. Show the period covered and the latest update. Unknown should look different from healthy.
A fictional dispatch decision
Consider a fictional equipment rental business. A return is overdue, and another booking needs the same equipment. The dispatch lead must choose whether to wait, arrange an approved substitute, or ask the account owner to renegotiate the next booking.
A fleet utilization chart might describe the wider business. It does not settle this choice. Dispatch needs the next promised handover, the current return estimate, the inspection requirement, and suitable substitutes that are genuinely available.
Use a decision card to commission that view:
| Field | Fictional decision card |
|---|---|
| Decision | How should dispatch protect the next confirmed handover when a return is overdue? |
| Owner | Dispatch lead; account owner handles changes to customer promises. |
| Trigger | Expected return plus required inspection time runs past the preparation cutoff for the next booking. |
| Information | Return estimate and its source timestamp; next handover commitment; inspection duration; substitute availability and suitability. |
| Actions | Wait with a scheduled recheck; reserve an approved substitute; request a revised commitment through the account owner. |
| Constraints | Dispatch cannot promise an unapproved substitute or change agreed pricing. |
| Missing information | Contact the responsible source; mark timing unknown; set the next check before the remaining preparation window closes. |
| Record | Chosen action, responsible role, affected booking, and next check or completion condition. |
This scenario illustrates a design exercise, not a client engagement or a claim about rental industry standards. The fictional business would need to define its own inspection rules and preparation cutoffs.
Suppose the return estimate leaves enough preparation time. Waiting remains a legitimate choice, with a recheck attached. If the estimate slips beyond the cutoff, dispatch examines substitutes. If none qualifies, the account owner receives a specific booking to renegotiate rather than a vague alert that “utilization is high.”
That sequence suggests a booking-level work queue with a compact detail view. A chart may help explain patterns later. It need not be the main event.
Design the action, including the boring aftermath
The screen should make it clear whether someone has merely viewed a problem or taken responsibility for it. Acknowledging an alert does not reserve equipment. Clicking a button labeled “Resolve” does not tell the next shift what happened.
Carry the affected record into the next step so people do not have to search for it again. Show pending requests separately from completed actions. Give deferred decisions a next review point; otherwise “later” becomes a very polite deletion command.
Before buying a custom interface, try the card with a simple list and the existing tools. Ask the decision owner to work through a routine case and a case with missing information. Note which facts they ignore and which they still have to request. Revise the card before commissioning the furniture around it.
Sometimes reporting is enough
A monthly report can be the right product when its purpose is historical review, a board discussion, or a stable record of performance. Readers may need to understand a period rather than intervene in an individual case. Clear definitions, consistent comparisons, and commentary can serve that purpose without buttons or alerts.
Exploratory analysis also deserves room before anyone can name a repeatable decision. Label it exploration instead of inventing an action to justify the build.
Commission a report for understanding, a work queue for recurring intervention, or a dashboard when the overview genuinely helps. Demand a reason for every chart. “It looked empty there” is a shit requirement.