What should a custom dashboard solve? From data to decisions

Except if you still have to work out what to do with that information, you've mostly created a tidier place for the same uncertainty.

A custom dashboard becomes useful when you want to bring data together around a specific decision or action. Which enquiries are waiting for review? Where is a schedule getting stuck? Which customer needs something? That determines what should be on the screen.

Start with a recurring question

Take one situation your team regularly encounters. A project manager might want to know every morning which projects are at risk of running late. An overview of all hours worked isn't an answer yet. You also need to know what was planned, what's left to do and which deadline is at risk.

For each measurement you want, write down who uses the information and what they can decide afterwards. If nobody can explain that, the measurement probably doesn't need to be on the first screen.

That makes a dashboard smaller and more useful. A management overview and a screen for the planning team can use the same data without needing to look the same.

A dashboard can be a place to get work done

It's easy to think of charts when you hear the word dashboard. But a list of five enquiries that need attention today can be far more valuable. Especially if you can open, complete or assign an enquiry straight from that list.

One example is a dashboard for a CRM provider where the team first reviews incoming leads and contacts them to arrange a call. Only after that check are the leads passed to its own CRM. The dashboard supports a specific step in the work, including the action that follows.

Make that distinction in your own project too. Do you only want reporting, or should the dashboard support day-to-day work? The latter brings in permissions, statuses and a record of changes. That affects the scope.

Agree on what the figures mean

Before combining data, you need to be clear about what you're counting. Is a new customer someone who created an account, accepted a quote or placed a first order? All three can be useful. Mixing them together mainly makes an overview confusing.

The same applies to timing. A revenue figure without a period, or a stock level without its last update time, only tells part of the story. For your most important data, agree on:

• Which system does this data come from?
• What is the definition, and who is responsible for keeping it consistent?
• How current does it need to be for the decision?
• What do we show when data is missing or out of date?

Not every screen needs to refresh every second. A monthly overview calls for a different update frequency from a screen for assigning new enquiries. Choose based on the work, because constant synchronisation also adds technical complexity and maintenance.

Existing software or a custom dashboard?

If you mainly need standard reports from one system, first look at what that system already offers. Existing reporting software can also be a good fit if the main challenge is combining and displaying figures.

Custom development becomes more useful when your process needs specific roles, actions or integrations. For example, when someone has to assess data from several systems and record a decision in the same environment. You want to avoid sending them back to four browser tabs and a separate spreadsheet.

Custom development also means making decisions about management. Who gets access, who can change a definition, and what happens when a connected system changes? Include that in the project so there is a clear owner after handover.

Do you want customers to track requests or review documents themselves? That also raises questions about the features and roles of a customer portal. Work out separately what your team does and what customers should be able to manage on their own.

Test it against a real working day

A design filled with perfect sample data usually looks clear. Real work brings long names, missing information, duplicate records and enquiries that have been waiting for weeks. Use those situations to test the dashboard.

Ask a future user to complete a specific task. Can they see what needs attention? Is it clear why a status is red? Can they move forward without asking a colleague to explain? You'll learn more from that than from asking whether the screen looks good.

Then start with one clearly defined process and the data it needs. After launch, measure how much manual preparation remains and whether tasks are easier to complete, for example. Expand once you know what the team actually uses.

Want to discuss a dashboard with us? Bring the overview or spreadsheet you currently work with. It often shows straight away which questions keep coming up and where a custom solution could make a difference.