Dashboard Fatigue: Designing for Action over Observation

For actionable business intelligence, we recommend starting with the decision a person needs to make, then choosing the measures that support it. For each operational dashboard, write down who will use it, what they can change and when a response is needed. Keep reporting for longer-term analysis, but give immediate work its own view rather than expecting every chart to generate an action.

Start with a decision, not a chart

Take a hypothetical service team deciding whether to move work between engineers before the next shift. Begin with that question, rather than a request to display every available measure of performance. Show the unallocated jobs, their deadlines, the skills required and the capacity available to the person making the decision. Put the job records behind a link so that the manager can check the details before assigning work.

For each proposed measure, ask the owner to finish this sentence: if this changes, I will consider doing something different. If nobody can name that decision, move the measure to an analytical report or remove it from this operational view. That is our design test, not a claim that historical reporting has no value. Keep a separate space for exploring trends and checking whether a policy worked over time.

Separate urgent alerts from routine work

The GOV.UK Service Manual advises teams to match monitoring to their support obligations and reconsider alerts for issues that could wait until morning. Its guidance concerns running digital services, but we recommend applying that distinction when designing operational business reporting too. Choose whether each exception belongs in an immediate notification, an assigned work queue or a scheduled review. Do not turn every movement outside a target into an interruption.

Define the response before setting the threshold. Write down the condition, the responsible role, the permitted action and the point at which the issue should be escalated. Test the rule against ordinary fluctuations and known exceptions before enabling notifications. For example, exclude a planned closure from a rule intended to detect an unexpected lack of activity. Treat that exclusion as an explicit business rule which an owner approves, rather than a hidden assumption in the chart.

Keep the overview visible even when no exception needs attention. Show that checks have run and distinguish a healthy result from missing information. We would not use a blank screen to represent both states.

Make the next action inspectable

For the hypothetical service team, an exception card might read: a job needs a qualified engineer before the next shift, and none is assigned. Under that statement, show the job reference, the deadline, the source records and the person responsible for allocation. Offer a route to review suitable engineers, rather than a button that silently reassigns the work. Keep the reason for the exception visible while the manager checks availability.

Do not present the suggested response as an established diagnosis. If the rule detects an unassigned job, say that, rather than claiming the team is understaffed. Ask the owner to confirm whether the problem is capacity, missing information or a record that has not been updated. Record the decision and its reason beside the exception so that the next reviewer can see what happened.

Use clear status labels alongside any coloured indicator. WCAG 2.2 says colour must not be the only visual means of conveying information. For this dashboard, pair a warning colour with text such as “Awaiting allocation” and a link to the affected work. Use a separate label for “Data unavailable” rather than assigning it the same appearance as an acceptable result.

Show whether the data is fit for this decision

The Government Data Quality Framework defines timeliness in relation to the data's intended use. For the allocation example, agree with the manager how recent job and availability records must be before they are used to suggest a reassignment. Show when those records were collected and when the dashboard last received them. Display any known gap in coverage next to the recommendation.

For a field team, include a state for devices whose latest work has not yet reached the reporting system. Do not label an inspection as missed solely because the central system has no completion record. Ask the manager to check whether it is overdue, still in progress or waiting to synchronise. If the information needed for a decision is missing, make checking that information the next task instead of presenting a confident recommendation.

Keep the definition of each operational measure accessible from the dashboard. Specify what counts as an unallocated job, which records are excluded and which time zone determines a deadline. Ask someone outside the implementation team to reproduce an exception from its source records before accepting the dashboard.

Test the response, not the number of views

Run a limited trial with one operational owner and one recurring decision. Before the trial, agree what would count as a useful change, such as less time spent checking allocation exceptions without more incorrect reassignments. Record when each exception was created, acknowledged and resolved, together with its final outcome. Review unnecessary notifications and missed cases as well as successful interventions.

Do not treat opening the dashboard as proof that it improved the work. Compare the trial with a defined baseline and note changes in workload or staffing which could affect the result. Keep the first version small enough that the owner can explain every rule and challenge every suggested action. At Dendro Logic, we recommend agreeing that decision and its acceptance test before choosing the reporting tool.

Update, October 2026

For a later discussion of measurement in engineering teams, see our article on the AI productivity paradox. Use it as further reading when deciding what evidence to collect for a trial of AI-assisted work.

Sources

• Government Digital Service, "Monitoring the status of your service", 23 October 2024, revised edition.
• Government Data Quality Hub, "The Government Data Quality Framework", 3 December 2020.
• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", 5 October 2023.
• Dendro Logic, "The AI Productivity Paradox, and the Team-Context Infrastructure That Fixed Mine", 1 May 2026, further reading for the October 2026 update only.