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.
Show comments