ISYS3438 Chap.9 Interactions and Dashboard Decisions
Interactions and Dashboard Decisions
A dashboard should provide a visible path from overview to location, diagnosis and action. This chapter evaluates selection, filtering, coordinated highlighting, navigation, KPI cards and tooltips against that path. It explains why control state must remain visible and why critical definitions cannot live only on hover.
The worked redesign reduces a crowded operational screen to a ranked status view, linked trend and service detail, with only the controls that change a decision.
What this chapter covers
- 01
dashboard hierarchy
- 02
selection and filtering
- 03
coordinated views
- 04
visible state
- 05
key performance indicator context
- 06
usability testing
Worked example · free
Turn a chart wall into an investigation route
- +1Lead with current delay, change and affected appointment count.
- +1Rank branches by level and direction.
- +1Link branch selection to a trend and service breakdown.
- +1Keep only decision-changing filters and show their state plus reset.
Key terms
- Coordinated view
- A coordinated view updates or highlights related panels in response to a shared interaction.
- Dashboard state
- Dashboard state is the active combination of filters, selections and parameters.
- KPI card
- A KPI card presents a compact measure together with enough context to judge it.
- Tooltip
- A tooltip reveals additional detail for a mark without permanently occupying display space.
Interactions and Dashboard Decisions FAQ
How many charts should a dashboard contain?
There is no useful fixed number. Include the views needed for the intended decision route and remove duplicates. A smaller dashboard can still fail if its hierarchy and state are unclear.
What belongs on a KPI card?
A measure, unit, period and relevant benchmark or change belong together. The audience should know whether higher is better and what action follows without opening another document.
How do I test dashboard usability?
Give a new user realistic tasks such as finding the worst branch, explaining the change and resetting the view. Record hesitation and wrong turns as design findings, then retest after revision.
Assessment move
Write a four-step dashboard script: overview, locate, diagnose and act. Map each view and control to one step. Ask another person to follow the script without coaching and observe where state or meaning becomes unclear. Treat every extra click, hidden definition and ambiguous reset as evidence for revision. Design from a decision route rather than a collection of worksheets.
Write the audience's first question, the comparison needed to locate an issue, the detail needed to diagnose it and the action available. Assign one view to each necessary step and remove views that repeat the same evidence. Establish visual hierarchy so status and exception appear before secondary context. A compact dashboard is not automatically clear; its sequence must be visible without an instructor explaining it.
Specify every interaction as an input and effect. A selection may filter, highlight, navigate or reveal detail, and the user should be able to predict which. Keep active branch, period, category and parameter state visible in titles or a filter summary. Provide a reset and test combinations that yield no data, one record or conflicting filters.
Do not hide essential definitions, thresholds or caveats in hover because tooltips disappear from exports, recordings and many accessible workflows. Build KPI cards around interpretation. Define the metric and time window, provide a benchmark or prior value, show direction and retain the denominator or sample size where it affects judgement. Colour should reinforce a documented status rule rather than invent one.
Link a card to the view that explains its movement. If the card says performance fell, the coordinated detail should let the manager identify where, when and for whom without changing the population silently. Run a usability test with a realistic operational prompt. Observe first attention, wrong turns, interpretation of state and whether the user can cite visible evidence for the final action.
After the task, change a filter and ask whether the recommendation remains valid. Record defects as hierarchy, wording, data, interaction or recovery problems, then revise the cause. Finish with refresh time, ownership and known exclusions. A decision-ready dashboard supports action, recovery and audit, not merely exploration.
Create a dashboard state matrix with rows for default, single selection, multiple selection, empty result and reset. For each state, record the visible title, active filters, affected views and action available. Test the matrix in the published or recorded format, not only inside Tableau. Add a recovery route wherever a user can become stranded or mistake an old selection for the current population.
Ask a peer to recreate one reported finding from the saved state and note any ambiguity. This matrix turns interaction quality into inspectable evidence. It also helps ensure that the same numbers and recommendation appear in the workbook, report and executive narrative. Save screenshots of the default, investigated and reset states with a sentence explaining the decision at each stage.
Compare them for title, filter and population consistency. If a screenshot cannot stand alone in a report or recording, add visible state or supporting explanation before relying on that dashboard moment as assessment evidence.