Presenting System Metrics to Senior IT Management

23FEBRUARY2018

Dashboards are incredibly popular today in a range of organizational areas.  For instance, within information technology arena, dashboards can be useful in tracking help desk tickets, system uptimes, or network performance, just to name a few applications.  They can be a fantastic way to communicate just the right information—all in a glance. We recently had the opportunity to create one when a longstanding client asked us to design and implement a system metrics dashboard that is tailored for their Senior IT Managers. Not surprising, what they wanted was different than the dashboards we had already created for their Helpdesk Technicians and Network Engineers. The IT Managers had different key metrics they wanted to track, and the granularity to which they wanted quick access. 

As we planned the dashboard design, our main considerations included the key metrics for our target audience, how to intuitively communicate data about those metrics, and how to balance granularity or “drilldowns.” To begin understanding the IT managers’ key metrics, it was crucial for us to ask goodquestions.  Generally, we stayed away from monosyllabic yes-no questions, instead focusing on open-ended ones, and doing our homework before the client meeting. Thankfully, we had some user logs to draw from and real users to interview.  After our requirements gathering and user interviews, we established which metrics were of most interest to the client. In this case, they wanted to see the collective uptime over the past 24 hours of a subset of critical business applications, whether or not any of those applications were experiencing issues and not resulting in unavailability, network-related events, data center events, and finally database events. 

Alt

Once we decided on the metrics to communicate with the dashboard, then came the question of ‘how’to illustrate them.  We had to not only consider which factors made sense given the data itself, but also the limitations of the software that the client had selected. For the application uptime, we selected an area chart (think—line graph that fills from the bottom) that shows the uptime trend over the past 24 hours. When it came to events with applications—the network, data centers, and database events—we chose to display symbols that came with the dashboard software, along with the corresponding text statuses for those symbols. In particular, we felt this redundancy would be helpful as some statuses could look very similar from a distance.

Now, what about those drilldowns? For each, we did not want the user to feel overwhelmed with too many layers or levels of information, but we also wanted to let them know more information was available to them if they desired it for the applications, network, data centers, and database events. Therefore, we included buttons beneath each respective symbol with the text “See all events.” Clicking on this button, or anywhere on the section of the dashboard for that component, took the user to a list of all events related to that component (applications, the network, data centers, and database events). 

At the end of the project, the client was pleased with the results and so were we.  Having put in the effort upfront by doing our homework, being diligent in gathering the requirements, interviewing users, and listening to the client really paid off.  We were able to successfully identify the IT Managers’ key metrics, display them intuitively, and balance granularity of the displayed data.  As a result of this project, our client will now be able to more effectively manage their critical applications, network infrastructure, database and data center operations. We hope to replicate this method and repeat the success we had in the future.