Or a security analyst could use a dashboard to quickly assess the general vulnerability of a network and which devices are sustaining high or increasing levels of attack. He could then respond by doing more in-depth forensics to shore up vulnerabilities in the network’s defenses or determine whether attacks have breached security.
Information dashboards can be very valuable to users. Unfortunately, dashboard design often follows the following progression:
- A product manager recognizes the need for a dashboard or hears people talking about dashboards at a happy-hour networking event and adds this requirement: “Product shall include a graphical dashboard on the home page.”
- Engineering scours the database schemata to see what data the system collects and displays it in bar charts and pie charts on a dashboard.
- Someone decides the dashboard needs to be more graphically appealing, so Engineering renders all of the charts in 3D and adds more colors. If the team includes a graphic artist, perhaps that person designs widgets that emulate the kinds of dials one might find on an actual car dashboard, then says, “Get it? It’s a dashboard!” at the stakeholder walkthrough.
We can do so much better than this. The purpose of this column is to investigate how UX professionals can improve on the all-too-typical process I’ve described and drive product teams toward meaningful dashboard design.
In Information Dashboard Design, Stephen Few offers the following checklist for designing dashboards:
- Organize the information to support its meaning and use.
- Maintain consistency for quick and accurate interpretation.
- Make the viewing experience aesthetically pleasing.
- Design for use as a launch pad.
- Test your design for usability.
For more about Stephen Few’s perspectives on information dashboard design, read Pabini Gabriel-Petit’s in-depth review of his book, Information Dashboard Design: The Effective Visual Communication of Data.
In this column, I’ll embark on a two-part discussion of dashboard design from a UX perspective. The focus of this column is on how to analyze user requirements and define actionable design goals for information dashboards and how to represent data on them, giving an overview of the more common graphic elements for displaying data in meaningful ways.
Analyzing User Requirements for Dashboards
Here are some high-level questions and considerations that should guide the analysis process:
- What data should we display?
- Where should we place the data?
- What kinds of interactions do we need to support?
- How should we represent the data?
Let’s look at answers to each of these questions.
What Data Should We Display?
UX professionals can help their product teams avoid an initial scavenger hunt for data to display on a dashboard by getting their teams focused on user needs. Asking the following questions can be helpful in determining what data to show on a dashboard:
- What is a particular user’s main reason for visiting the dashboard? Is the user making a decision or reacting to specific events or situations?
- What triggers a user’s visiting the dashboard? What happens that prompts the user to view the dashboard? Is there some information the user would routinely review at the start of a work day? Or would a user go to the dashboard in response to a system-generated email alert?
- How frequently would a user visit the dashboard? Once a week or several times a day?
- What is a user trying to assess? Does the dashboard answer questions such as How are we doing? If so, complete that question: How are we doing at what?
- What critical decisions does a user have to make? For example, would the dashboard inform the user about any reallocation of resources? If so, it needs to make the most critical information available to help the user make an informed decision.
- Are there conditions of which we need to alert a user? For example, an industrial control dashboard might alert the user that a critical parameter is out of range. This is similar to the gas gauge or engine-temperature gauge on a car’s dashboard, which not only informs a user about a quantitative state, but alerts the user if the amount of gas in the tank is low or the engine temperature is too high.
Where Should We Place the Data?
You need to decide how to arrange the data on a page—not based on the aesthetics of the page, but on the ways in which the information flow must support users’ workflows. Get answers to the following questions:
- What are the critical must-see or must-do items? Give these items prominent placement and stronger visual treatments.
- What is the likely flow of a user’s focus? Graphic elements pull users’ focus downstream.
- Is there a logical grouping scheme? Express groupings visually.
- Would a user want to compare some data with other data? Place comparative data side by side.