In my last article "A Road Map to Realizing a Dashboard from a Software Developer’s Perspective", we discussed the Business Logic and how it should take care of massaging the data into a consumable fashion for the Presentation Layer. In this article, we are going to discuss common User Interface (UI) functionality that is associated with dashboards.
Davis: “Okay, when I select a date range, I want to drill down into the Sales Revenue by Rep”.
Sivad gives a quizzical look and answers : “Davis, before we continue discussing the user functionality of the dashboard, let’s clarify some terminology”.
Sivad makes a good point. Before going any further, it is important to discuss some of the terms that will be used in this article. Note that these terms may be defined slightly different by business analysts.
Drill Down: This functionality describes the ability to click on data that will show related data either in the same area or in another dashboard. Figure 4.1 shows the former and Figure 4.2 shows the latter. The most important thing to note is the user clicks from a data visualization component.
Figure 4.1
Figure 4.2
Filter: This functionality describes the ability to look at the data differently by having the user select various report parameters. Figure 4.3 shows a sample list of report parameters that the user can select from to narrow down the view of data. An example of filtering would be to select a time range of the data; i.e. the user would select a start date and end date and the dashboard would update its values accordingly.
Figure 4.3
Hover over: This functionality describes the ability for the user to see a preview of related data to a particular metric by putting their mouse over a data visualization component. Figure 4.4 depicts this functionality.
Figure 4.4
Davis: “Thanks for the clarification. It’s important we speak the same language when discussing functionality from a high level perspective.”
Sivad: “I agree. It’s also very important that you get involved with the functional requirements because in the end, you’re the one who will be using it! Okay, so here is usually how I tackle the functionality.”
The Dashboard Filters
The filters of the dashboard should be determined first. Use the metrics to help decide on the appropriate filters. In Sivad’s case, he has the following metrics:
- Daily Sales Revenue
- Performance of Reps (Daily Sales Revenue, by Day, By Rep)
- Revenue by State (Daily Sales Revenue, by Day, by State)
As a rule of thumb, any metric that is categorized will have an associated filter for a category. I use the term category loosely here. In this case, I am referring to time ranges, reps, and states. What will truly define the filters will be how this data will be visualized; i.e. in the next article, I will discuss the data visualization of this dashboard in more detail and this will ultimately determine what filters will exist in this dashboard.
For this particular dashboard, it’s logical to have a date range filter. The type of date range picker I like to use is a calendar control complemented by a selection of the range (e.g. month, quarter, year, two years, and five years). This makes more sense than allowing the user to pick any random end date which may result in showing only 7 days. The point is to see a trend. Of course, one can add a week option to show a week’s trend should that be desirable.
Performance of Reps indicates there could be a Rep filter so as to be able to clearly see how an individual is doing relative to the company average or whatever the bench mark is.
The Revenue by State metric indicates there should be a filter to select the state.
The Dashboard Drill Downs
A potential metric for drill down functionality can be determined by the following:
- The metric is categorized by a similar dashboard. For example, the Sales by Rep metric has the potential to lead to a Rep Performance Dashboard. In this particular case, the user would click on the Rep, and the Dashboard System would jump to another Dashboard.
- The metric is an aggregation and the metric is comprised of various categories. For example, the Revenue by State metric may be comprised of various locations. The user would click on the state, and it would replace the current visualization with a visualization based on location. Note that if this approach is taken, then there should be an intuitive way for users to go back up. Usually a web link bread crumb or a back button is used.
The Dashboard Hover Over
The best use for the hover technique is in scenarios where you just need a preview of information or to show a breakdown of a metric. Be careful with the latter. If you have too much data to show the hover over will be less effective. For example, if you had total revenue for a particular month, and you wanted to show the breakdown with a hover over of the sources of revenue, and there are 20 streams of revenue, it may be too hard to clearly show what each stream contributed as depicted in Figure 4.5.
Figure 4.5
For Davis’ dashboard, there is potential to use a hover over to show the daily sales breakdown by Rep. Now, you may feel that I’m breaking my own rule, but for this hover over, I will only show who the top performer was for that day.
Sivad has only described the major functionality in a dashboard to Davis, but there are many others that he has not mentioned to him. Hopefully, in the future, I will have a technical article that describes all the functionality I have come across in my experience.
Article Summary
In this article, I discussed the common User Interface functionalities and where they may be applied. Ultimately, it will be the dashboard layout and the data visualization choices that will drive the dashboard functionality. In my final article, I will discuss how Sivad will discuss the presentation layer and bringing all these articles together.
Copyright 2008 - Dashboard Insight - All rights reserved.