Shipping primitives instead of reports

Every fixed dashboard is a guess

A vendor building reporting has to decide in advance what its customers will want to know. Ticket volume by day. Open items by team. Average resolution time. All reasonable, all correct for somebody, and wrong for most people on the day they start using the product.

What follows is familiar. The backlog fills with requests for one more chart. Each is individually sensible and none is worth a release on its own. The reporting section slowly accumulates views that made sense to one customer three years ago, and the product gets heavier without getting more useful.

The alternative is to stop guessing. Ship the parts, let people assemble the view they actually need, and spend the design effort on making sure what they assemble is readable.

That is harder to design than a fixed dashboard, because the person composing is a supervisor or an operations manager, not a designer. The system has to produce acceptable results from people who are not thinking about layout at all.

Fixed size, movable position

When a widget is created its dimensions are set. In edit mode the person arranging the dashboard can drag things into a different order, but not resize them.

This is the constraint the whole thing depends on. Free resizing sounds generous and produces unreadable results — a chart squeezed to a third of its useful width, a list stretched until it holds four rows and a lot of nothing. Give a hundred non-designers unrestricted layout control and you get a hundred dashboards that look broken, and a product that appears to be at fault.

Fixing dimensions guarantees every dashboard looks deliberate, while movable position leaves people the decision they actually care about: what belongs at the top. Constraint here is a kindness, not a limitation.

Composed dashboards are shared with the team

A dashboard someone builds for their own role is usually right for everyone doing that role. Sharing within a team means the person who thought hardest about which numbers matter does that work once.

Staying current without churning

Widgets refresh on an interval, or fetch when a push signal tells them something has changed.

That hybrid is deliberate. Pure polling wastes requests on data that has not moved — a dashboard checking a quiet queue every ten seconds, all day, for nothing. Pure push means streaming full payloads and handling reconnection, ordering and replay for every widget on every screen, which is a great deal of machinery for a number in a box.

Signalling that something changed and letting the widget fetch keeps the transport simple and the screen accurate. The interface cost is that refreshes must not disturb someone mid-read: values update in place, the layout does not reflow, and nothing jumps under the cursor.

Admitting the primitives will not cover everything

Five shapes and two data sources still will not answer every question a business has. The honest response is to say so in the design rather than pretend otherwise.

External page embeds something the platform does not hold. External endpoints let widgets read data it does not own. Both are escape hatches, and both exist because the alternative — a customer asking for something the widget set cannot express, and waiting for a release — is worse than a slightly less pure product.

Pre-built dashboards sit alongside composition for the same reason in reverse. Some questions genuinely are universal, and making every customer assemble them from scratch would be dogma rather than design.

Common questions