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.

We were thrilled when we first found out that the Federal IT Dashboard had incorporated our JuiceKit treemap. A year later, the dashboard has been relaunched:

U.S. CIO Vivek Kundra relaunched a IT Dashboard today, and, well, the thing almost makes navigating federal tech spending data fun. Kundra told Politico's Morning Tech that the inspiration for the redesign are online tools people might use to navigate their stock portfolios. The new dashboard offers up more data on spending on more than 7,000 federal IT projects

The first time around, it was awesome to see transparency and visualization brought to the federal government. This time, some of the excitement has worn off and we're going to use it as a case study for "opportunities" to design a better dashboard. There are five areas where it can be significantly improved:

• Message
• Flow
• Charts
• Context
• Design fundamentals

(Not coincidentally, these are the types of areas we cover in our Viva Visualization Tour. Next up, Boston August 25th.)

---

Part 1: Message

The information designer is responsible for presenting the data in a way that the message is delivered in a clear and understandable way. If the data is left to speak for itself, users can be left confused or frustrated. And in all likelihood they won't to see the full value of the data. That's particularly tough for this Federal IT Dashboard where a huge amount of effort has been put into gathering consistent data across agencies.

The goal of this dashboard is clearly stated on the landing page:

“The purpose of the Dashboard is to provide information on the effectiveness of government IT programs and to support decisions regarding the investment and management of resources.”

They want to answer a couple fundamental questions: Where is money being spent on IT projects? How effective are those projects being managed? Unfortunately the data isn't presented in a way that novice users can quickly answer those questions. Instead the dashboard raises more questions than it answers. For example:

A giant chunk of overall spending goes to the Department of Defense. But how big are these numbers? How are they changing?

Pie charts show that something is mostly green--but not entirely. What does this represent? How should I feel about mostly-green performance?

The three ratings lines are converging around 7.5. What are these numbers and what is driving the trends?

We took the liberty of sketching up a revised dashboard that would more effectively talk to the message of IT program cost and performance. Our dashboard has two primary views, spending and performance.

IT Spending. Where is the money going? Here we have highlighted the top spending agencies and those that are seeing the greatest increases in spending. The line chart on the right shows the trend in spending for any selected Agency. In this way, a user can click on items that they are interested in and immediately see what has happened over time. Labeling also matters. We included titles that would be easy for the first-time user to understand.

Performance. How effectively are the projects being delivered? In this view, we have included something we call a "Spike Chart"; it is a specialized version of a Parallel Coordinates Chart. The Spike Chart allows you to track the performance of the same entities (i.e. Agencies) across multiple performance criteria. The chart will quickly reveal which Agencies bubble to the top (or the bottom) and how they perform across different evaluation criteria.

Within each view, we would let people see the data either by Agency or Investment. In both cases, the resulting visuals are focused on showing which entities are spending/performing the best/worst--and how are the values changing.

There is a ton more functionality embedded in the Kundra's IT Dashboard, but we'd argue for hiding that away until the user has understood the most important and/or interesting information. Then they can drill down into the specifics of a project or organization.

If you're interested in learning more about how to design better dashboards, check out our white paper Designing Dashboards People Love to Use.

Grocery shopping at a new store is a drag, no matter how thoughtful the supermarket layout or how clear the signage or how wide the aisles. I have a mental model of my local supermarket that makes my trip efficient and helps me avoid that frustrating "double back" to search for the peanut butter.

This thought made me wonder about the importance of familiarity in dashboards. We spend a lot of time at Juice designing intuitive, simple-to-use dashboards. We want to create a logic and cohesiveness that ensures the right things are placed in the right proximity and order; sales leads should connect to prospects in the same way as the peanut butter and jelly is shelved near the bread.

If you are starting from scratch, this internal logic and consistency is paramount. But how about a dashboard that is already familiar to the target audience? Does it makes sense to redesign a dashboard for usability if it is already heavily used and understood?

For many dashboards, the purpose is simply to convey a few key nuggets of information. Without a series of interactions or tasks, the user's only need is to locate and absorb data. In these cases, the measure of success is whether the user can find what they are looking for quickly.

I can appreciate the value of familiarity over usability. When the new Microsoft Office "menu ribbon" was introduced, it was described as a convenience to new users because it displays the most relevant features for any given context. For power-users it broke the experience; all the effort I'd put into memorizing static menus was lost.

For all our concerns about poorly-designed dashboards, it may be familiarity that explains why it can makes sense to keep the status quo.

The following is an excerpt from our three-part series: "A Guide to Creating Dashboards People Love to Use". It is chock full of best practices and practical tips for designing dashboards. This particular nugget is something we've used to great effect and wanted to make sure our readers didn't miss out simply because they were afraid of ending up on our mailing list. There is even a movie version.

We’d like to offer a simple framework for effective use of fonts in your dashboard. With a few simple decisions, you can ensure that the text on the dashboard will both look good and communicate effectively. The majority of text on the page falls into four categories:

• Body text is clean, readable content
• Headers separate and name major sections of your work
• Notes describe additional things the reader should be aware of. These should fade into the background unless we call attention to them.
• Emphasis text is what we want our reader to pay particular attention to.

The following table describes an approach for deciding how to display each of these text types. The yellow highlights indicate where you need to make decisions.

It comes down to three basic decisions:

• Choose size and font of the body text
• Decide if the header is going to flip to serif or sans-serif—and whether it is going to have any style
• Decide what to do about emphasis—color or (bold or italic)

A few things things don't fit neatly into one of the four text categories listed above, such as table headers and graph titles. We tend to use a combination of styles to handle these exceptions.

Stick to this framework and we guarantee your dashboard will look better. Take a look at this example, starting with a standard-looking Excel report without out much thought put toward the fonts:

---

The following version of the same report cleans up the table, chart, and fonts:

---

A final version uses Georgia for the title font and brings in a new emphasis color. The result: a totally different but equally clean and readable report.