Business Intelligence Dashboard for Communications Tracking

A data visualization designed to support a client team’s tracking and cross-collaboration

 An outline showing how a Communication Package goes from ideation to a public announcement.

The users of the dashboard were identified as members of two offices: the Administration Office and the Communication Office. Members of both offices needed clarity into the Communication Package Release (CPR) Process in order to collaborate, quickly identify blockers, and take action to mitigate them.

The users requested that information be stored strategically so that blockers or “flagged” Communication Packages can be seen quickly without having to “drill down” into the details of a Package. Each office was also interested in a slightly different “view” of the information. While the Administration Office was mostly interested in high-level summary, the Communications Office was interested in more detailed information.

ADDITIONAL QUESTIONS

When reviewing the context of the project and the information provided, the client was transparent in letting our team know that they were unclear of how some of the information around the Communication Packages should be structured, and that their own team needed to align on how many and which sub-steps they wanted to use to track a Communication Package. We let them know that we would support them through this process through prototyping, and that the purpose of early prototypes would be to get all team members (client and my team) on the same page as far as understanding what the users would need.

Some key questions that the client wanted to explore were:

• Can we also “track” the progress of Strategic Initiatives in addition to Communication Packages?

• How would the progress of a Strategic Initiative be dependent on the progress of Communication Packages?

  • In other words, how does the data roll up?

  • Do we have access to that data?

• What are the sub-steps of the CPR process? Is that information that would be useful for a user to see?

• What do we call these sub-steps?

DEFINING THE PROBLEM DESPITE UNKNOWNS

While there were some unknowns about the data, what tracking process would work best, and the actual steps involved, we decided to define problem statement based on the information that we knew at the time. Our team understood that our initial prototypes would elicit more information from the client and compel them to think through what made the most sense for them when defining steps in the CPR process that worked best for them. We communicated to the client that together with them we would be able to work through these kinks in our regular bi-weekly meetings.   

We created the following problem statement to work with:

Members of two offices within the Federal Government Agency (the Administration Office and the Communication Office) need a comprehensive tracking system that allows them to see the components of each Communications Package, where each Communications Package is in the process of being released to the public, and blockers that may prevent the Package from being released on time.

FIRST PROTOTYPE

Prior to using software, I always hand-sketch views to start to understand how the layout would work in displaying the data, even if I only have a generalized idea of what the data would be.

Even though the information did not yet exist, I was given the go-ahead to design a page that would portray the progress of a Strategic Initiative as dependent on the progress of the Communication Packages within it. I used the client’s brand colors while also using orange and blue for the data in order to accommodate users with colorblindness.  

Because there were 15 Strategic Initiatives, I wanted to be sure to show progress for all 15 on one view and I was inspired by the idea of small multiples showing the tracking progress. I used bar charts that would “fill up” as a Strategic Initiative got closer to its goal and small flags to quickly show which Strategic Initiatives needed attention from the Administration Office. On the left side panel, I wanted to show an example of what it would look like to have a quick summary donut chart of the numbers provided on that page.

When a user would click into an Initiative, they would be taken to a landing page showing them all the Communication Packages for that Initiative.

When a user clicked into the Communications Package, the third view was a more detailed overview of the Package. It included information such as the objectives of the package, the components of the package and additional details.

FEEDBACK ON FIRST PROTOTYPE & ADDITIONAL REQUIREMENTS

While the first prototype was well received, I received the following feedback on the design:

• Release dates need to be prominently displayed for each Communication Package.

• The user needs a way to see what Communication Packages will be released in the next 30 to 90 days.

• While the first view connecting the progress of a Strategic Initiative to the progress of the Communication Packages within it is ambitious, it is not a priority right now and may not make sense because the Initiatives are never quite “finished”

  • However, the view without the bar chart does feel useful in allowing the user to click into an Initiative to see which Communication Packages are housed within it and see which have flags.  

In interacting with the prototype, the client shared it would be useful for the user to drill down into each part of the CPR Process, and that additional sub-steps should be added for Strategy Development and Clearance.

FINAL PROTOTYPE

In reviewing all of the feedback, I decided that it was really important for the user to be able to filter for Communication Packages through two ways:

1. By release date: this would allow the user to see what Communication Packages have release deadlines not just in the near future, but also within 30 to 90 days.

2. By Initiative: this would allow a user to be able to see all Communication Packages within one initiative as well as see which Initiatives have the most or least Communication Packages.

I drew a simple flow chart for the information architecture of the next prototype.

I then created screens for each of these positions on the flow chart:

 Here are the highlights on how features within the screens address the requirements and user needs.

 The client team was pleased with this final version and it was presented to the users to view and test. The users approved this version to go into development.

 REFLECTION

• Designing a data visualization product requires close collaboration with the client, especially if they need the visualization to further understand how they can use their data. In this project, the client was really appreciative of the prototyping process because it allowed their team to hone in on what data pieces were important to the users and how to organize the Communication Package Release process so that it was streamlined and understandable for everyone involved. Sharing prototypes with them allowed them to further imagine how the data could be organized and manipulated differently for each user. As we got further along in the process, they became more and more excited about what was possible with the data they had.

• Share prototypes with the development team early and often. This design was created to be developed in Tableau. While Tableau is a powerful tool, it has some constraints and I needed to communicate with the developers to understand what functionalities and styles were and weren’t possible. We did not want to provide designs to the client that would oversell what our development team could feasibly produce.

• Continue to collaborate. This project is currently in development and I continue to work with the development team to redesign parts of views when the users realize their needs might have changed.