Dashboards: The Simpler the Better

I am, extremely grateful for how far technology has come when it comes to reporting in 2020. The functionality needed to create dashboards is pretty standard in today's cloud based applications. Many even give the user the ability to create or at least configure their own dashboards without the need for a single technical degree. So what's the deal with dashboards? Where do I even start?

The purpose of a dashboard is to provide information to a person that is actionable and consumable. The dashboard should be, by definition, purpose driven. That singularity of purpose is what separates the dashboard from any other report you might find out there. For a simple example, take what I would consider the ultimate dashboard, the exercise apps on an Apple watch. Here you see two watch applications that are used by runners. Both have similar functionality but we can see very quickly that although their purposes are similar, they are not the same.

If you want to build a dashboard that is truly loved, whether a simple heart rate monitor or a sales pipeline, ask yourself the usual questions:

Who: The first question is always who! If we don't start by asking ourselves who will be using our dashboard, then the dashboard will literally be designed with no one's best interest in mind. So start by asking about the role of the person consuming the information. In the case of the heart rate monitor, is it the athlete or the coach? Could it be a doctor investigating complaints of chest pain? Each of those dashboards would likely look different because each person has a different set of needs and interests. In the case of a sales pipeline, it would be very important to ask whether the sales people are using this dashboard or the sales manager. Maybe the production department needs a sales pipeline dashboard. It's great that everyone wants you to build the dashboard, but don't assume that the sales pipeline needs one dashboard, it might need three or more.

What: Next, we need to know what the user is doing or trying to accomplish with the help of your dashboard. Just as important, what are we planning to measure for that role in order to allow them to do that job? Take the heart rate app as an example. On any given day, I may be going for a run on the same trail, wearing the same watch and hoping to know very different information. If I'm doing interval training and I need to keep close track of my heart rate, the zones app is highly applicable. It makes my heart rate very obvious and even shows me which zone it falls in using the colorful dots above. If I'm training for a 5k and I'm more interested in my split time along with heart rate and distance, I opt for the apple running app. This app gives me several pieces of information that I need to put together while I'm running, so it needs to be very easily consumed at a single glance. When I return home from either type of run and I want to see the entirety of run vs. a point in time snapshot, I want to see an entirely different dashboard.

Where and When: We must consider the environment that the user finds themselves in when the consume the dashboard. As we discussed, the running apps are perfectly suited for watch because they need to be extremely mobile. This limits our real-estate tremendously and asks us to be hyper-sensitive with space. No frills here. Of course when we get home and are looking for summary statistics, we are likely going to use our mobile device or even a tablet or desktop. This gives us tons of space in comparison and we can of course make use of that space. But don't fall into the trap of trying to fill the space just because it's there. Remember, a dashboard should be concise and very specific to a person trying to get a job done. If you feel eager to give the user the ability to see related items, give them a link to more detailed reports.

Why: Just as "who" is the first question to ask, "Why" is the most important. Now we know all about the role of the user, we understand the job they are doing, we understand whether they are in the office and the point of the process that we are discussing. Before we design anything, we need to know why the user would like to have this dashboard. What unfilled need is to be met? What lack of understanding or gap in information exists? What's wrong with what they have now? What's right with what they have now? What are they having to correlate in their heads? Unless we understand the real unmet needs, the design of the dashboard could be answering all of the wrong questions!

When it comes to dashboards, it's not about what technology you use or whether you are able to create the most friendly UI. Strive to create the most easily consumed version of the most actionable information that a user would need to do a job.