A few principles for internal dashboards

Internal tools are used by the same people every day. That changes what good design looks like.

Internal tools have an unusual audience: a small number of people who use them every working day, often for hours. They know the business better than we do, they are in a hurry, and they will find every shortcut the tool allows. Designing for them is different from designing a public product, and a few principles have served us well.

Start from the decision, not the data

Before drawing a single chart we ask: what decision will someone make after looking at this screen? Reorder stock, call a customer, approve a refund. A dashboard that answers that question in one glance is worth more than one that shows everything we could measure. We usually end up with fewer charts than the first draft, and one clearly highlighted number.

Tables are underrated

Charts are good for trends; tables are good for work. Most daily tasks involve finding a specific row and doing something with it. A fast, sortable, filterable table with sensible defaults often replaces three charts and a search page. We make sure the table remembers the user's last filter, because people return to the same view many times a day.

Make the common action one click away

If eighty percent of visits end with the same action, that action belongs on the first screen, next to the item it applies to. We watch how people actually use the tool during the first weeks and move buttons accordingly. Small changes, like approving several items at once, can save each person a surprising amount of time.

Show where numbers come from

Trust in an internal tool disappears the first time a number disagrees with the spreadsheet someone keeps on the side. Every figure on our dashboards shows when it was last updated and, on hover, how it was calculated. When the numbers are late, the screen says so plainly instead of showing yesterday's values as if they were current.

Keep permissions simple

Most small companies need two or three roles, not a matrix of permissions. We start with "can view", "can edit" and "can approve", and only add more when a real situation requires it. Every change made through the tool is recorded with who made it and when, which answers most questions before they become disagreements.

Plan for the person who inherits it

Internal tools often outlive the project that created them. We keep the code conventional, the dependencies few, and the setup documented in a single README, so that whoever maintains it next can make a small change without first learning a new framework.