Juice Analytics

Most dashboards just talk and don’t listen. Have you ever been in a “conversation” with someone and they talk 90% of the time. They ask you a question and while you’re 15 seconds into answering they interrupt and starting offloading their mountains of insight. It’s mostly about them. And their consideration for you? Not so much.

That is what most dashboards do. Blah, blah, blah. What if…

What if the information presentations we interacted with actually acknowledged who they’re talking to, listened more, and talked less? What if we were to replace the focus on data with a conversation and a way of working out the complexities of data between two or more people.

To do this properly, think about what a “good conversation” is. Here are a few characteristics we came up with:

• The people have similar experience around a topic; so they know what they’re talking about, but because every person is unique, they’ve gathered unique insight that can be shared. The varying, educated perspective keeps the conversation interesting.
• The one doesn’t overly interrupt the other. Sure there may be reasons to interrupt here and there, but, if interruption is the norm, it quickly gets as annoying (and rude) as your cable news political analyst.
• There is a sense of genuine care for what the other person is saying because, well… there is a genuine sense for what the other person is saying. Too often people get caught up in the “tricks” of networking and small talk and “the hook.” What if people actually respond to what’s genuine?
• Distractions are minimal. One person isn’t constantly checking their phone or entertaining other interests. People are very adept at sensing interest. They do this by reading you: body language, eyes, word usage, how you breathe, pace of speech, and inflection to name a few. If you are actually interested in hearing what another else has to say, they will know.
• You trust the other person. There is an assumed authenticity about each other. This is slow to build and easy to break.

So there’s a few qualities of good conversation, but why? People don’t often stop to think about why they enjoy good conversation. Let’s look at the benefits:

• Your perspective is sharpened. You don’t have to live through the same experience the other person did in order to benefit from their insight. That is, if you trust what they are saying. This is a big time saver! Imagine if no one acted on anything but personally experienced information. You may know some people like that. They flounder, spending more time re-discovering rather than benefiting.
• Your momentum is accelerated. Good conversations with trustworthy friends or experts is one of the biggest ways we overcome obstacles and keep momentum in life.
• A dependable relationship is formed. You know if you ever want to talk about “x” topic again, where to turn. As the trust is built in that conversation, you are also setting this person as someone you can turn for solid footing when future steps are required.
• Great conversations lighten your burden. Joking isn’t trivial, in fact, some the most serious conversations benefit from humor. It promotes an open mind and releases misplaced pressure over circumstances.

Now, why is a designer at a visualization, dashboarding, software company talking about all these warm fuzzies?! Presenting information is about people. We’re adamant about that at Juice. We’ve been focusing on what people actually want out of their data for a long time. Why? Because it’s a hole in the market and it’s fundamental to knowing what people both need and want to see out of “information experiences” they encounter. Until we appreciate the qualities and benefits of good conversations, we don’t have a firm foundation for sharing and communicating data.

You’re saying, “Well, that’s all fine and good, but how in the world does this play out in an application or dashboard?.” I’m glad you asked. This concept is something of deep interest at Juice and the thoughts here represent the tip of the iceberg. As we actively work through these concepts, we’ll look to provide practical examples in the coming months.

Questions
What are some of the qualities of an enjoyable conversation you’ve had this week?
How did it affect your day?
In what ways could you imagine your dashboard just talking and not listening?

Dig Deeper
This talk by John Cleese (of Monty Python’s Flying Circus) is one of the best on creativity I’ve ever seen, and it speaks to the seriousness of humor, for the jokesters among you.

Evaluate and apply some related design principles to your application: Make it conversational, Use common language, Consider data comfort and expertise.

Spring is a great time to spruce things up.  While you’re at it, consider adding a little shine to you and your skills.

We’ve made it easy for you by adding five more videos to our resources page that will help sharpen your saw, as Stephen Covey might say, in this important area of your life.  From graphing to table design, color to typography best practices, you’ll find these video tutorials full of tips, tricks and tidbits that you’ll be using long after the pollen rinses away and your antihistamine goes back in the drawer.

And, just in case you’ve been fogged over, we launched a new page on our site a few weeks ago, Design Principles. If designing from the human perspective interests you, you’ll find this a valued extension to your knowledgebase.  

Achoo! (That is, here’s to you!)

[Insert witty opening here].

You see? In principle, when writing a blog post, I know it draws you (the reader) in to continue reading by starting with a story or something smart or a joke. Don’t overwhelm people right from the get-go. Start with metaphor or phrase that relates to the article.

That introduction relates to what I’m really interested in talking about: principles. We’re launching an exciting new resource today, and it has to do with principles, design principles that is. These resource will remind you to do things like use gradients appropriately or provide instruction. Their goal is to direct your design towards information presentation that focuses on the human element.

Engineers start with technology. MBAs start with funding. Designers start with people. The trick is to get interdisciplinary teams to raise their collective I.Q. by working in the overlap of those three areas. That’s where innovation flourishes.Moggridge

At Juice, we start with people and great consideration for that overlap. Therefore, we’re not only about what information to show but also how to show it. And behind those two basic ideas is an awful lot of thinking > developing > learning > and iteration. Through that process we’ve gathered a (rather long) list of principles that inform our decisions, and we hope it can help you with yours too. Rather than trying to be sure your application supports all principles, approach it more like a stack of flash cards and pull out the relevant ones. With experience, you’ll realize you’re doing these things naturally and understanding the drivers of design thinking is invaluable to introduce objectivity into application design.

There are two parts to this:

1. View the list and explore the content on our Design Principles page.
2. Engage in discussion on our Quora Design Principles Board.

This list will likely grow and shrink over time through the refinement process. The descriptions of each principle definitely will. Our goal is not to be exhaustive, but helpful.

There is a slight catch. So far, we’ve only fully a few of the many principles, which means we have a long way to go. We’re going to embrace process on this one with what might appear to be a (very intentional) turtle’s pace. Still, we’ve made the titles as concretely informative as we could before filling out all their content. Feel free to to run (err walk) right along side us or check in every now and then to evaluate your projects against the list. If you find these helpful or would like to share your experience or opinion on any of them we invite you to engage in the discussion, vote up and down the principles you find more or less useful. Share your insights why. Let us know which one you’d like to see next. Keep us honest, and the visualization community successful. Happy designing.

Clear bright white and nostalgic colored string lights adorn otherwise commonplace trees and shrubbery on nearly every block this time of year. Neighborhoods and shopping centers look like beautiful storybook villages as we pass, enjoying our commutes a little bit more in spite of the holiday traffic.

On my drive home last night, the thought occurred to me that data is a lot like holiday lights. When organized in an attractive and appealing dashboard design, the power of data is enhanced and can be even more powerful and meaningful. Data, when displayed in a striking new way can be more intriguing to us, and as a result, we’re more likely to engage with it. Perhaps we would have missed the very same data had it been organized and presented in a less pleasing fashion.

By presenting data in a way in which our psyche is predisposed to receive it, we allow our audience to see and hear the story that we have to share, and then help them gain clarity and understanding around the data. It is then that we have their attention and the opportunity to make a point, deliver a pitch, close a sale or ask them to make a decision.

Sharing information in a context in which people are open and most receptive to receiving it is intuitive. It’s human nature to appreciate attractive things, especially pretty lights, to give and receive beautifully and thoughtfully wrapped packages and to look forward to the promise of a brand new year.

Merry Christmas and Happy New Year from the Juice Team!

Tis the season of indulgence. Sometimes it is indulgence without any semblance of restraint. Case in point, the “Cherpumple” — a combination pumpkin, apple, and cherry pie framed in icing.

When it comes to business dashboards, the gauge chart is often a case of indulgence without restraint. It can be equal parts waste of valuable pixels, low information, and visually deceptive. It would be a lot smarter to use a bullet chart — but who wants to pick the the fruit plate for desert?

Gauges have undeniable appeal to dashboard designers everywhere. Perhaps it is the “skeuomorphism” of a gauge chart. That is, it borrows from the look of something we are familiar with as a way to make us feel comfortable or understand its purpose.

In the past, I’ve fought the good fight against these charts. Now I’m resigned to the fact that eradication is impossible. If that’s true, can we at least find some ways to make them better through design? Tone down the brilliant sheen and high-contrast colors; turn up the information conveyed.

First we can start by making them look better. Web designer Christian Annyas shared a beautiful gallery of Chevrolet speedometer designs across the years. Here are a couple of my favorites:

Christian even offers a decent argument for gauges over simply showing a value:

“It’s easy for a driver to get used to a needle that rises and passes numbers that are located on fixed positions. A quick glance is all it takes to see and understand the value it represents.”

Let’s take one of those designs, overlay a few necessary data elements, and see if we can create something worth looking at.

1. Start with an classy Chevrolet design that lays out so as not to take up too much valuable vertical space
2. Add subtle indicator of good and bad zones with green and red dots
3. Show the current value with a bold label
4. Display distribution of recent history to communicate how the value has changed

While this chart is still far from efficient in its data-to-ink ratio, at least it communicates the small amount of information effectively. Any ideas for how to make it better?

Using proper dashboard design techniques is a topic that struck a chord when we released our white paper series
“A Guide to Creating Dashboards People Love to Use” a few years ago, and still seems to resonate as people regularly download the content from the Juice Analytics website, and we receive ongoing requests to speak around these key principles.

Since we can all use a little calibration every once in a while to stay in tune, we thought we’d post it again, with a reminder that you can access this oldie but goody, along with other materials on the Juice Analytics resources page anytime — and that all of these materials are available to you gratis.

Should you have a friend, colleague or know someone who could benefit from a little dashboard design “religion”, feel free to let them know where you found yours.

Do you have your child’s drawing on the wall of your cube, office or maybe at home on the fridge? Can you remember visualizing the world that simply?  When was the last time you looked at anything quite that way? What if you did?

Well, we did just that. And, our effort resulted in a video to share with people about what we do here at Juice.  We hope you like it.

(P.S. Thank your kid for the artwork covering that stain on your wall — and for the great analogy.)

Juice’s own Ken Hilburn brings it home at the Strata conference. He sits down with Mac Slocum of O’Reilly for a few data softballs. Here’s a second-by-second account.

[0:03] Q: What are the most common visualization mistakes that people are making?

[0:03] A: The bottom line is usability. Stay focused on your purpose, making decisions, taking action. Stay simple, if you have to explain you’re failing.

[0:15] Brett Favre endorses Wranglers, but Ken wears Data Wanglers [not shown].

[0:59] Dropping names, and twisting the knife on usability.

[1:25]? What better time to confront a little gap in your knowledge than when you’re being filmed? It’s Antoine de Saint Exupéry.

[1:48] Q: Do we need different tools to create simple visualizations?

[2:05] Plentiful shout outs to friends in the industry. Even Business Objects gets a friendly mention, is Ken getting soft?

[2:53] A difficult point to cover in a short time. We speak of data journalism and telling stories with data, but there are really no great tools that allow this in an everyday business environment. There is a lot of attention, not much progress.

[3:15] Q: What makes a great dashboard?

[3:25] A: Zach and Ken just delivered a 3 hour tutorial on the subject earlier in the week. Can Ken cover it in 30 seconds? Attention, context, and data drilling are keys but there’s precious little time to do more than mention big concepts.

[4:20] Q: Are dashboards too complicated?

[4:22] A major softball to close the session. Cheshire cat grin from Ken.

[4:54] “Getting your brain around it.” What Ken isn’t saying is that we know today’s businessfolk aren’t just looking at one dashboard, they have to look at many. They have to integrate info from lots of disparate systems into a picture of how their business is doing. If your info is harder, more complex, presents a bigger cognitive load, or is slower to load, then it’s going to be less valuable.

If you haven’t had the pleasure of getting to know Ken, stay tuned. We’ll be doing more Viva Visualization events in ’11 with more detailed prescriptions for great dashboards and there’s no better way to spend your morning than eating a nice warm bagel and listening to Ken.

This is the third in our series of topical reviews of the Federal IT Dashboard. As Ken noted in his discussion of Flow, we see this publicly-available dashboard as an opportunity to share some thoughts on ways to evaluate and improve dashboard design, while acknowledging the hard-work and challenges that went into its development.

Today we’d like to take a quick tour of the charts in the Dashboard and ask three questions of each:

1. Is it the right chart for the data being displayed?
2. Is the chart designed to communicate effectively?
3. How would we redesign the chart?

A column chart is used to display the top departments by IT spend.

They’ve chosen an appropriate chart for the job, though we often will go with a bar chart over a column chart. Bar charts tend to use space more effectively because the category labels can be wider. Notice how all the Federal Agency labels had to be compressed into an abbreviation (e.g. DOD, DOC, DOT, DOJ), almost requiring a beltway-insider to translate.

One quirky feature is that the y-axis is labeled “($) Billions” but there are no values on the bars (on rollover, a tooltip shows the values with “$B”).

Finally, the chart uses animation when it is first displayed to grow each of the bars from the baseline. This is a useful effect that emphasizes the largest values which keep growing after the others stop. Not as useful: the reflection effect under the chart doesn’t help with comparing column sizes.

Our redesign of the chart would include more explicit labeling and the total IT spending at the top.

Pie charts are used to show the distribution of performance of IT projects.

We’ve said a lot of mean things about pie charts over the years. We are not alone. Nevertheless, pie charts can have a legitimate place in presenting data. Here’s how these pie’s fall flat:

• At their miniature size, the relatively proportions are hard to see.
• On the summary page, there is no legend or labeling to provide any meaning. I appreciate that green is good and red is bad, but what are the definitions for those colors?
• As always, a 3d pie chart distorts values by making the “closer” slices seem bigger.
• Readers will find it difficult to compare across the three pie charts.

An alternative to multiple pie charts in this situation is a stacked bar chart:

Line and area charts are used to display trends in project performance.

These charts are appropriate and reasonably well executed. Our concerns would be with the design: the labeling isn’t efficient for the limited space, the lines colors aren’t high contrast, and the entire chart feels like it was compressed into too small a space. Here’s our take on it:

A treemap is used to show the composition of projects and/or spend based on agency, functions, service groups, etc.

Is this the right chart for the job? Most definitely. Treemaps are awesome at displaying hierarchical data that can be summed at each level. It provides a comprehensive view of IT spending composition while allowing you to see changes and drill-down for more detail.

The design of this treemap needs refinement. The developers used the out-of-the-box version of our JuiceKit™ treemap, so we have room for improvements in our default settings. For example:

• The borders on the boxes are clumsy and distracting. We’ve started to de-emphasize the border with white or light grey.
• The label names provide very little value as most of them are a truncation of the word Department. A narrower font at normal weight would help. Creating an alternative label that leads with useful information would be better: “Commerce” rather than “Department of Commerce.”

Here’s a treemap demo that feels a lot cleaner from a design perspective:

All in all, the Fed IT Dashboard does a fine job of choosing appropriate visuals and keeping the chartjunk low. Here are a couple good source to help with these decisions:

• Chart Makeovers
• Choosing the right chart type
• Chart chooser, for Tufte-compliant charts
• Choosing a good chart

This is the second part in a series about better dashboard design. This part, Flow, follows Message to highlight the importance of taking that message and making it easy to work through in light of the larger business process.

Having said that and before we continue, we wanted to reveal an internal conversation we’ve been having about the example (Federal IT Dashboard) that we’ve selected to demonstrate some of our thinking. We appreciate that it is hard to build dashboards that satisfy a broad audience. From initial conception to delivery, these forces, often at cross-purposes, can chip away at an intuitive and clear design. This series of posts isn’t meant to disparage the hard work and deep thinking that clearly went into the design of the Fed IT Dashboard; it is meant to offer some perspective and hopefully useful lessons for others in their dashboard design projects.

Part 2: Flow

In Part 1: Message, Zach introduced the results of some thinking we’ve been having about the Federal IT dashboard and how to continue to improve the effectiveness of its ability to communicate with data. This week, we’ll take a look at the next step in the process: Flow.

Communicating with data is like telling a story: there’s a beginning, a middle, and an end. When you grab that latest book from your favorite author, you know just where to get started, and (if that author is any good) you know exactly when it’s the end. Well, telling a story with a data application is just the same. The information designer needs to lay out the components of the story in a way that facilitates starting, learning, and finishing strong. We call this the workflow of the application. A great application workflow is not evidenced by easy-to-use software (although this might very well be a byproduct), but rather a great application workflow is about helping the user transparently achieve the objectives that make them successful at their job.

So let’s look at some of the principles that we at Juice would use to take the flow of the Fed IT dashboard to the next level.

Principle 1: Know what objectives people are trying to achieve

The first step to knowing the objectives of the users is to know who the users are. Because of the tremendous reach of the Federal IT Dashboard, this is a particularly difficult problem as the audience is so broad. Generally speaking, we think there are three types of users for this system:

• Inquisitive masses – Scope: broad but shallow – These folks are the general public; those people who are most likely looking for high level information and are looking for answers to broadly curious questions.

• Informed but distant 3rd parties – Scope: medium breadth, medium depth – This second group includes people who are looking for information on a specific program to compare to another program that they are more familiar with. In the case of the Federal IT Dashboard, this may include the CIO of a related project, or the chair of a Senate subcommittee, or a political watchdog group doing some research.

• Involved 1st parties – Scope: narrow but deep – This third group represents those who are directly involved with a specific program and want to drill deep to learn as much as they can about a single specific program.

Principle 2: Know how the solution will fit into the broader workflow

Since most “normal” people are paid to get stuff done and not paid to use software, it’s important for the application designer to make sure the tools that they provide are, at a minimum, supporting the workflow, and preferably, transparent to the workflow. Questions that the designer wants to make sure the user doesn’t find themselves asking are “Where do I start?”, “What’s the next step through the app?”, “What’s the end point and how do I know I’m finished?”.

Looking at the Federal IT Dashboard homepage, it’s not clear to me that there’s actually a place to start. The very first image is the Performance summary on the left with the column chart on the right. But just as I’ve decided that I can click, the image changes. I find myself being confused by this almost every time I visit this site – especially since I can’t click on the other views in the image rotation. All of a sudden, I’ve gone from trying to complete my workflow to trying to figure out how to get back to the dashboard – not very transparent.

Using existing methods such as behavior diagrams (such as Interaction Diagrams, Event Diagrams, and Use Case Diagrams) can really help an application designer overcome these sorts of hurdles and define intuitive action flows.

Principle 3: Make navigating the application layout intuitive

When considering application navigation layout, use a single simple rule: start high and enable drill down.

Start with high level KPIs that indicate the overall performance with as few metrics as are possible so the first thing that the user sees on a dashboard is nearly instantly comprehensible. This sometimes requires the application designer to be ruthless about “who” makes the metric cut for the first view. The number should immediately indicate whether further investigation is required. In our mockup, the important numbers are just four: spending and change, and performance and change.

The goal is that it’s simple enough that a first time user can quickly determine what’s next, but an experienced user can quickly determine if anything significant has changed since their last visit.

Once the high level “first view” is identified, enable the user to easily drill down for additional information and exploration. For example, as the user is investigating a particular number, clicking directly on that number should reveal the next layer of information. This is where the Federal IT Dashboard excels, by the way. Users can drill down by clicking on program names, or chart segments, and can navigate back up the crumb trail by clicking “clear” at the top of the data table or on the current view parent.

Finally, we need to address the main navigation. Navigation elements that are positioned such that they imply some sort of relationship, such as menu items, should either be siblings, or parent-child entities. In the case of the main navigation tabs on the Federal IT Dashboard, the items Home, Portfolio, Tools, and Data Feeds are distinct areas but all have different relationships to each other – or worse aren’t related. This makes navigation difficult because the user has to context shift to navigate. It’s a little like “Apples”, “Transportation”, “Monday”, and “Swimming” – they don’t have any thing to do with each other.

It’s OK to use tabs, but make sure they contain distinct and separate domains or views. For the Federal IT Dashboard, I think navigation would be more intuitive if the Home, Portfolio, and Tools tabs were merged. Start all the users with the overview, then allow them to navigate via the visualization to the Portfolio view. Then, toggle that view with the views that under the Tools tab based on the view the user needs to see.