Designing dashboards people actually use

Before I designed a dashboard for planners and management, I did something that felt slow at the time and saved me weeks later: I studied a pile of existing enterprise dashboards and the UX research behind them, instead of opening a blank canvas and guessing. The people who would use it knew their problems cold. What they couldn't tell me was what the screen should look like, because translating a pain point into a visual is a design job, not a user job. So I went looking for what already works, and here's what the research kept repeating.

Do the homework before the pixels

It's tempting to start in Figma. I started in articles. I ran a desk-research pass across real logistics and enterprise dashboards, plus design literature from UX specialists and data-visualisation references. The reason is simple: those existing dashboards were already built for a similar audience and usually informed by their own user research, so they encode a lot of hard-won decisions I'd otherwise have to rediscover by trial and error. Reading them first meant my concepts could stand on UX principles and still carry my own project's requirements, instead of being a pretty guess.

A recurring lesson from that reading: users often know exactly what hurts but not how they want to see it solved. That gap is the designer's actual job. They'll tell you "I can never tell which containers are late." It's on you to decide that this becomes a map, or a sorted list, or a red KPI at the top.

Put the important things where the eyes land

Nearly every good dashboard leads with KPIs at the top. It sounds obvious, but it's a real principle: the most important numbers should require zero scrolling. You open the page and the state of the world is already in front of you, and everything below is detail you go looking for. If a user has to hunt for the headline metric, the layout has already failed them. Navigation tends to sit on the left, often collapsible, so people can find what they need and then push it aside to give the data room to breathe.

Use the right chart, not the most charts

The biggest "bad practice" I saw, especially in dense, auto-generated dashboards, was too many charts at once. It looks impressive and communicates nothing, because the viewer can't tell what's important. A dashboard's job is to turn data into an insight, not to display everything you happen to have. The fix is matching the visualisation to the question being asked:

• Line charts for trends over time, and for anything you want to project forward.
• Bar charts for comparing things against each other.
• Maps when the data is fundamentally about where. Plotting where containers physically are made a pattern obvious that a table would have buried.
• Tables only when someone genuinely needs to read the exact numbers.
• Infographics when you're combining a few values with text to tell a small story rather than show a precise figure.

Picking the chart is half the work. The other half is restraint: every element on the screen should be earning its place by answering a question someone actually has.

Never show a blank white screen

Performance is a design feature, not a backend afterthought. A fast dashboard gets used, and a slow one gets quietly abandoned no matter how good the data is. Two habits matter most:

• Don't reload the whole page. When a filter changes, update in place instead of throwing the user back to a blank state.
• Show skeletons, not blankness. A skeleton placeholder tells the user "this is loading and here's roughly the shape of what's coming," which feels dramatically faster than a white screen even when the real wait is identical. Perceived performance is performance, as far as the user is concerned.

And for anything operational, stale data is worse than slow data. If the numbers auto-refresh, say so with a clear indicator. Never quietly show yesterday's figures as if they're live, because in a logistics context that doesn't just look bad, it causes real decisions to be made on wrong information.

Filters are what make it usable

Static dashboards are posters. Useful ones let people interrogate the data, and the research drew a clear line between merely good and genuinely best:

• Good: the basic filters exist at all. Date, type, category.
• Best: filters can be combined, results apply instantly with no lag, and the active filter state stays visible so users always know what they're looking at.

That last point is easy to forget and constantly causes confusion. A number looks broken until you realise a filter three sections up is still applied. Keeping the filter state on screen is a small detail that quietly prevents a lot of "is this chart wrong?" moments.

Encode meaning in colour and shape

Colour and form aren't decoration. They carry information for free if you're deliberate about them. Darker shades can signal intensity or urgency, so darker reads as "needs attention" without a single word of explanation. Shape and texture can encode a second dimension on the same chart: a dashed line for historical or projected values against a solid line for actuals, for instance. Used consistently, these conventions let someone read a chart at a glance instead of stopping to decode a legend every time. Used inconsistently, they do the opposite, so the rule is to pick a small visual language and stick to it everywhere.

The one that's easy to miss: let people act

This was the insight that reframed the whole project for me. An operational dashboard isn't there to be admired. It's there to help someone do their job. The best ones don't stop at showing information, they let users take action on it directly. Surfacing a problem and putting the button to resolve it right there, next to the insight, closes the loop between seeing and deciding. For a logistics audience that might mean an action to reroute or reassign something the moment the dashboard flags it. Without that, you've built a very handsome report that someone then has to act on in a different tool entirely, which is exactly the friction a dashboard is supposed to remove.

The takeaway

The temptation in dashboard design is to start with the visuals, because that's the fun part. What the research taught me is that the visuals are the easy part. The hard part is deciding what deserves to be on the screen at all, what question each element answers, and what the user should be able to do once they see it. Do that thinking first, ideally informed by how other people already solved the same problem, and the pixels mostly design themselves. Skip it, and no amount of polish will save a dashboard that looks impressive and helps no one.