Charge Summary Dashboard

Design Process Overview

Deliverable: Wireframes
Programs: Axure RP 8

New Dashboard

Ingenious Med has a data analytics tool called Analyze, which provides interactive reports to our administrative users. One of these reports is called the Charge Summary Report, which I was tasked with updating.

The Problem

Old Dashboard

There were several layers of information hierarchy to work through, as well as additional requirements for what the dashboard needed to include. The current version of the dashboard attempted to show four categories of data per view, with different views based on what level the data was coming from (Enterprise, Group, Site, or Individual User). This proved ineffective as many of the options were hidden behind a "Filters" button and the graphs were too small, requiring a "Remaining Sites..." option below each.

My main goal was to reduce the levels of hierarchy, bringing more information to the forefront while still reducing clutter.


During the discovery phase, I investigated the dashboard and its many options. I wrote down all the different views, filters, sorts, and actions so that I could reorganize them later. I also started investigating dashboard designs that other applications and sites were using to see what practices they use for displaying several layers and options.


Once I had all the required elements written out and a repetoir of potential design elements, I began sketching ways that I could combine them all. I started with the graphs because they are the purpose of the dashboard, but they couldn't show enough data when they were as small as they were. I changed the view to only show one graph at a time with controls at the top to change the view to the other metrics. This allows for more detail to be shown in the graphs but hides data from the other metrics. To compensate, I included metrics from the current time period in the controls, so that a user has some knowledge of how they're perfoming without having to click anything.

The filters in the old version contained time selectors as well as data selectors. I chose to separate those by containing the time selectors and the graph in a panel, while grouping the view selectors (which I dubbed "Organize By") and data filters in a left hand column. Now having brought all selectors to the main page, I wanted to bring in the raw data. I did so by including another panel below the graph for tabular data. To populate it, a user would click on a bar in the graph to see the data that it contains. The graph also had an excel export option, something asked for by our users.


The hardest part of this project was the compromise that happened when development started working on it. Everyone was excited about the design, but I heard over and over "we can't build that." The team was building this in a tool called MicroStrategy, not in web code. I didn't fully understand the technical constraints of their program, and that proved to be an issue. I spent some time working with the dev team, figuring out what they could and couldn't do. A good example is that the time selectors could not be free text - they could only display the range that was selected by the controls to the left.

After working with the team during their sprint, we came out with a product that was definitely the best dashboard in our analytics tool.