Understand your users
Designing an effective dashboard involves more than choosing charts. Understanding users, identifying their needs and presenting information clearly helps ensure the dashboard supports meaningful decisions and actions.
Never design a dashboard for everyone. Dashboards should support a clearly defined audience. Knowing user needs helps you focus on the information that matters most.
Before you begin, you should understand:
- who will use the dashboard
- what questions need to be answered
- what information, insights or messages need to be communicated
- what comparisons, decisions and actions need to be supported
- what risks, warnings or exceptions need to be identified
- how familiar people are with the data
- how much support or explanation people need
- where and how the dashboard will be viewed
- what accessibility needs must be supported
Write user stories to help define the needs, goals and outcomes of the dashboard. An example user story might be:
As a workforce manager, I want to see vacancy rates across my service area so that I can identify staffing pressures and prioritise recruitment activity.
This user story identifies:
- User: workforce manager
- Need: see vacancy rates across their service area
- Outcome: identify staffing pressures and prioritise recruitment activity
Define the purpose
Use your understanding of user needs to define what the dashboard must help users understand, decide or do. You should define:
- the main message or question
- the decisions and actions the dashboard should support
- the measures needed to support those decisions
- the comparisons, targets or trends that provide context
- the information that can be removed
Plan the content
Organise information around user questions rather than the available data. You should:
- show headline information before supporting detail
- group related information together
- separate groups where direct comparison would not be meaningful
- check that filters, breakdowns and drill-downs do not reveal sensitive or identifiable information
- plan how the dashboard will communicate loading, errors, zero values and when no data is available
- make methodology and governance information available when needed
Provide context
Help users understand what the data means. Where relevant, include:
- trends over time
- comparisons
- targets or benchmarks
- previous performance
- notable changes, risks or exceptions
- the reporting period and date of the latest update
- how often the data is updated
- data quality issues, limitations or caveats that affect interpretation
Avoid presenting numbers without enough context for users to understand what they mean.
Reporting suites
For reporting suites with multiple dashboards, use a summary page to help users:
- understand what the suite contains
- find the most appropriate dashboard
- access supporting information such as methodology and data quality reports
- see when the data was last updated
Keep introductory content concise. Avoid duplicating navigation that is already available elsewhere. Use navigation cards to group related dashboards and help users choose where to go next.
Filters
Before adding filters, consider whether users really need them. Base the filters you offer on the questions users want to answer.
Make it clear:
- what each filter controls
- which selections have been applied by default
- which filters and selections are active
- how filters affect the information displayed
- how to clear or reset selections
- whether filters apply to one visual, one page or the whole page
Once you have identified the filters users need, consider the appropriate filter position.
Sketch the layout
Create sketches or low-fidelity wireframes before building the dashboard. Use them to explore:
- where users should look first
- how related information should be grouped
- how much information can fit comfortably
- different ways of arranging filters, metrics and visualisations
When possible, test the wireframe with users before investing in detailed design. Testing does not need to be formal and you do not need to be a user researcher to gather feedback. Even a small number of representative users can help identify problems. Ask users to complete a few realistic tasks and observe whether they can find, understand and use the information they need. Focus on where they become confused, hesitate or need additional explanation.
Choose visualisations
Use the chart type that most clearly communicates the information.
Follow the guidance in choosing the right visualisation type when selecting visualisations. Different charts support different user needs and insights.
Avoid selecting chart types based on appearance alone.
Test and improve
Dashboard design is iterative. User needs, available data and requirements often become clearer as the dashboard develops. Revisit and refine earlier decisions as you learn more through testing, feedback and real-world use.
Before release, test the dashboard to check that users can:
- understand the main message
- find and use filters
- complete important tasks
- use the dashboard with a keyboard
- access essential information without relying on hover interactions
- understand the dashboard at different screen sizes and zoom levels
Testing can be simple
Testing doesn’t need to be complex or require specialist user research skills. It can be as simple as asking a small number of representative users to complete common tasks using the dashboard or wireframe.
Allow users to work through tasks in their own way. Avoid interrupting, explaining how the dashboard works or leading them towards the correct answer. Observe:
- where users start
- whether they understand what they are looking at
- where they struggle, hesitate or become confused
- what questions they ask
- whether they can complete tasks successfully
To understand whether the dashboard is solving the right problem. Ask users what they would like to achieve, what questions they need answered and whether the dashboard supports those needs.
Continue to gather feedback after release. Review content regularly and remove what users no longer need.
References
Neilson Norman Group
Usability (User) Testing 101
Office of National Statistics – Service manual
User personas