I used to work in finance (esp Market Data) and now I've ended up in Employee Analytics.
One thing I've observed is that a user's requirements always flip, and they're usually not aware of it. The two biggest bits of feedback I've heard are "too much data" and "not enough data" -- often from the same person, and occasionally on the same dashboard.
People just want the highlights, except when they don't, in which case they want everything. The former is really hard because highlights require a lot of rule-based context. The latter is also hard because "everything" is often meaningless. Too much flexibility in your data exploration tool and people just go on random fishing expeditions.
Now I try and structure data in terms of a conversation, with an information "needs" to determine the priority order. Start with the hurdle requirements (e.g. something key like sample size), move through the highlights then present the bare minimum to guide further exploration. If you make data exploration easy from that point it this seems to work well, but I'm still learning.
I must admit, I took one glance at the "ideal dashboard" and was a bit bewildered. I had no idea what I was meant to be looking at, or the relative importance of things. Perhaps there is some critical, specific domain knowledge that I'm missing. Either way, will definitely get this book to find out more.
Super glad that this is on the frontpage. Dashboard design is probably the single biggest thing that analytics companies overlook when building product. It took us nearly 5 iterations to get our dashboard to a decent point.
What's worst is when offering free trials of an analytics product and then realizing that all freemium customers engage with a dashboard once, and then dropoff forever. Event tracking and various stages of a/b testing can be dangerous because they steer engineers to local minimums in designing a product.
Having a logical understanding of every element of the dashboard is the best way to approach the design.
Great post, we need more resources like this out there.
Don't forget to add realistic sample data for new customers, too, particular if you have a freemium model. An empty dashboard will turn some non-technical customers away -- it does not tell a story nor show how the product will serve a potential customer's needs.
Just make sure there's a very easy (and non-destructive!) way to switch between real data & sample data.
I'm an educator so it was interesting to see the example of an education dashboard in the competition. This is something that we struggle with - every educator has different needs and so it's really a difficult challenge to satisfy teachers with digital solutions for their registers and record-keeping.
In this case, I was super-surprised that the letter grades were barely visible on the winning design. The post-competition design was far better in the respect that it displayed the key takeaways prominently.
The register of attendance was lacking in several aspects compared to the common/traditional way it's done on paper. For example, since we probably need to see exactly what dates/days/lessons were missed, having the data in a standard per-week format would be more useful.
From an educational point of view, we should want to use computers to improve the quality of the data, rather than just displaying the data prettily. It would be better to link together the available information to provide educational insight.
Ideally, we might want to say something like: "You missed the class on X, and performed poorly in those questions on the associated test, so you need to catch up by studying the following", using the dashboard to access this type of info.
Further thought: It would be awful to have the data displayed worst-to-best. The comments pick out that this is because teachers should spend more time on the worst performing students - in my mind, this is a fallacy (under-performing students, perhaps yes). Worse than that - I would typically want to easily identify the data for a particular student, in which case the data would be better in some consistent (alphabetical) order.
Bought Few's book. Information design is something I'm really interested in, yet I haven't found too many resources on it, other than Tufte's books (obviously) and a couple others. One of my favorites is Information Graphics: A Comprehensive Illustrated Reference by Robert Harris [1]. It offers little discussion, but is an excellent catalog of all of the various ways you can represent data.
For more exploratory information design, check out the stuff by Nicholas Felton. He's a big quantified-self guy who every year publishes a really nicely designed annual report of his life [2]. I emailed him once asking for more sources on info design and he linked me to the site of a course he taught that contained some great resources [3].
Good stuff, thanks for the links. Especially Felton's course page has several good references that were new to me. Ellen Lupton's Thinking with Type [1] seems a fun read. Great designs also on the competition page [2].
I would actually spend the money to buy Thinking with Type, if you're really serious about learning typography. Having the tree version lets you get really up close and personal with the various types, and it's easy to flip between pages to compare letterforms, etc. Another one to check out is Elements of Typographic Style [1].
KDP/Createspace [1] make it really easy to self-publish on Amazon. There really is no reason not to have ebooks at launch these days. Especially if you're self-publishing. There are plenty of apps that help (had to research this personally recently):
I've been working pretty extensively on our in-house dashboard. We've settled on the Dashing framework written by Shopify with some rather heavy customization.
The main focus has been on readability from long distances and the ability to switch context when up close using the leap motion.
What's powering your setup? I've also been using Dashing to create my company's internal dashboards and decided to hook a Raspberry Pi up to the display to show the dashboards. Unfortunately it's turned out to be massively underpowered, especially because our dashboards are pretty data / chart heavy. Was just going back to the drawing board when I saw your post.
Your experience is interesting because Raspberry Pi will be my first thought for a setup like this. Can you elaborate a bit about your load problems? You said your dashboards are heavy: are you doing heavy data elaboration on the rPi (i.e. getting data from multiple sources, calculating stuff etc..) or it is just too heavy for handling the ruby/sinatra site with data being pushed from outside via http?
From my experience of first trying a lightweight media center PC, leaving the browser open for extended periods caused pretty severe memory issues with the computer in general, that combined with the fact that Dashing itself is a Sinatra based application with a bunch of ruby jobs running in the background can cause some serious slowdown.
I really like the graphs at the top in the left most pane and the ability to swipe between dashboards. Are those public widgets/functionality? Or, did you add those?
All the charts were created using the built in rickshaw library. Most of the widgets are in house at the moment but I'm working to open-source as much of it as possible.
This guy has a few books that, from the face of them, seem very similar. Can anyone point out the important differences or give some advice (e.g. which to pick in what order)?
Information Dashboard Design - is definitely the first one you should read. It really gives a more high level overview of charting best practices and dashboard design.
Show me the Numbers - goes much more in depth about the details of the different chart types and visualization best practices. There's a chapter or two on each of the main chart types.
Now You See It - This is described as a companion book to Show me the Numbers and focuses on data analysis as opposed to pure visualization.
One thing I've observed is that a user's requirements always flip, and they're usually not aware of it. The two biggest bits of feedback I've heard are "too much data" and "not enough data" -- often from the same person, and occasionally on the same dashboard.
People just want the highlights, except when they don't, in which case they want everything. The former is really hard because highlights require a lot of rule-based context. The latter is also hard because "everything" is often meaningless. Too much flexibility in your data exploration tool and people just go on random fishing expeditions.
Now I try and structure data in terms of a conversation, with an information "needs" to determine the priority order. Start with the hurdle requirements (e.g. something key like sample size), move through the highlights then present the bare minimum to guide further exploration. If you make data exploration easy from that point it this seems to work well, but I'm still learning.
I must admit, I took one glance at the "ideal dashboard" and was a bit bewildered. I had no idea what I was meant to be looking at, or the relative importance of things. Perhaps there is some critical, specific domain knowledge that I'm missing. Either way, will definitely get this book to find out more.