Loose notes from SXSW 2010 session Why Your Baby is Ugly – Effective Dashboard Design, with Aaron Hursman of Hitachi Design. Though I’ve only ever worked on one dashboard system, I am interested in data visualization, and this was an excellent crossover session for both dataviz and information design concepts.
Recommended book: Information Dashboard Design
Definition: A dashboard is a visual display of information. Has to be a single screen, has to provide an overview of a system. Some aspect of data visualization. Has to be scannable and tell at a glance where the problem areas are.
If there’s a problem area, make it pop out (e.g. grey histogram but with red for the highest or lowest bar). Or if using columns of numbers, use a red diamond next to highest or lowest number.
Scatter plots work well as well – outlying numbers are immediately obvious.
KPI – Key Performance Indicators. Everything you put on a dashboard is a performance indicator but not necessarily a KEY indicator.
Don’t just show the total sales for this year – show how it’s changed from last year. People need to see both of these stats side by side.
There’s a time and place to provide interactivity.
An area of contention – there’s so much to display, there’s a temptation to hide things behind tabs etc. But you can end up hiding KPIs inadvertently.
A hover over can be very useful – Dim the background, bring out a balloon showing more info about a certain data point.
Consider using word-size graphics (Edward Tufte). A sparkline graphic can show 30 data points at once without having to have a giant block on the page – just inserted next to explanatory text, can convey a lot in a very small space.
Make exceptions pop by muting the background.
Don’t let your baby daughter wear shirts with printing in Comic Sans!!!
Stay away from 3-dimensional graphs. They look hot but aren’t really effective (and they can distort data).
Pie charts in general should be avoided if you have more than a few data points. The difference between 30% and 40% may be significant but can be hard to see in a pie chart.
Be really careful about which data series to include in a graph. If graphing the mass of planets in the solar system and you include the sun, everything gets skewed way off kilter.
Your dashboard doesn’t have to look a car dashboard, or like you’re flying a plane.
There’s a time and a place for treemaps and heatmaps, but be judicious. Overuse of these and you’ll need to have training to use the dashboard. A good dashboard requires no training to use.
Careful of glossy effects for polish – it makes regions look two-tone, which can confuse if comparing to a color legend.
Challenges: Users are resistant to change. People become very reliant on information. A new dashboard design can be upsetting, even if radically better. It’s tough for people to let go of their wubbies. Get to understand users – their needs and motivations. Are they tied to the desk, or mobile? What are their pain points?
Prototyping dashboards is tough because it’s so detailed. Tabula Software recommended – lets you build designs on top of mock data.
Always vet your ideas with the tool jockeys. If there’s a particular platform you’re going to need, make sure it will work with their back-end systems before beginning (naturally). Learn about the client’s APIs and toolchains before or recommending various tools.
Your dashboard is only as cool as the data that’s available to you. There’s a lot of work that has to happen on the data architecture side to make certain things happen.
This is a very time consuming process – more so than a normal web or mobile app. Build in lots of time for development and design. Fail fast, get things in front of users as fast as possible. Pay to get prototypes if necessary.