Data Forecasting Redesign

One of my first projects at LogicMonitor was to redesign one of their AIOps features, Data Forecasting. This redesign was part of a bigger feature, Resources page. Data Forecasting allows the user to to predict future trends for their infrastructure, using past data as the basis. This feature was originally created for to help ITOps developers troubleshoot and diagnose any issues they might encounter.

This project was a part of a bigger project (the redesign of the Resources page), so I served as the lead designer for Data Forecasting specifically while working with a designer who was leading all of Resources. In my role, I was in charge of mocking up the redesign and validating it with customers through user research.


April 2020 to October 2020

Dates


Worked with…

Tools

Sketch, InVision, Zoom

Teammates

Greg Nudelman (Design Lead), Peter Stradinger (UI Engineering Lead), Ryan Albert Donavan (Product Manager)


The Problem

Data forecasting wasn’t being used at all - Even though data forecasting had been around for several years before I had joined the company, it was an underutilized feature. Users cited the lack of readability, the modal taking up a majority of space, and the overall lack of use cases for data forecasting as primary reasons why they were not using the feature.

The UI is in need of a refresh - The UX team was put in charge of a multi-year UI refresh. At this point in time, we had just finished the first phase of the refresh, the Alerts page. The next phase in the UI refresh was redoing the Resources page, which is where Data Forecasting was. Aside from just giving the Resources page a UI refresh, our team wanted to improve the overall experience of the Resources page.


The Goal

To create an experience for forecasting that provides a user an increased return in value and experience compared to the current experience.


Initial Ideation

95th Percentile view before

95th Percentile view after

The first thing I did was started doing quick fixes on the data visualization. In the current UI, the background color showing the forecasted area in the 95% view was unreadable. I changed it to a more conventional forecasting visualization to make it more readable. For the line of best fit view, I nixed the background color and changed the line of best fit to a different line style and color for added differentiation.

Line of best fit view before

Line of best fit view after

Next, I started on adding more features that could potentially add in more value. The first feature that I added in was allowing users to turn on Forecasting while the graph was still in a widget. This design suggestion was taken from previous customer research, where users had stated they would be more likely to use it if they were able to attach it to a dashboard in the form of a widget.

I also decided to add in another feature where I would show a table showing the overall trend and bounds for the datapoint selected. I noticed that a user didn’t have any access to numerical data. A user could access any numeric data by hovering over the visualization, but I thought the current functionality wasn’t usable nor accessible. In the current iteration, screen readers could not read the numeric data, due to it being dependent on the hover. Additionally, a user constantly has to remain hovering the graph in order to see the data, making them unable to use their mouse elsewhere if needed.

While the rest of the features were well received in design reviews, there was one concern in regards to the table. Though, the tables were generally seen as an improvement, there was some concerns in regards to including it. By including tables within the forecasting, users would be less space to view more widgets on screen, thus taking away data density. I was unsure about this theory, I hypothesized, that by showing the numeric values within these tables, I would be adding more data density to this design.


First Round of Usability Testing

In order to determine whether the two hypotheses would be correct, I decided to do a round of user testing. Seven users of varying degrees of experience with the Resources page were interviewed. They were given the following tasks:

  1. Turn on Forecasting

  2. Switch between the 95 percentile and the line of best fit visualizations

  3. Change the data point being forecasted.

Overall, users had a positive reception to the new design, below were some of the main findings.

Users thought showing it on a widget was an improvement - They thought that showing the forecasting on the widget by default was a significant improvement to the current iteration. One reason why they preferred the new design over the current iteration was because it was just a widget, not a modal, they could turn on forecasting for multiple datapoint widgets. By doing so, it would be easier for them to predict any outages or an overuses, as they could just take a look at the resource dashboard to see if any of the datapoints were acting unusual as opposed to opening up a bunch full screen widgets one at a time.

The table was seen as an improvement, not a detraction - When asked about the table and whether it would be a concern in regards to space, users had little concerns. Users actually thought that the tables were an improvement to the current prototype, as would provide them additional numerical data. They could see the overall trend, instead of having to guess the overall trend that they were looking at by hovering over the graph.

There were only two major points of confusion for users - Users were only mildly confused the table was showing multiple datapoints when there was only one datapoint shown. Additionally, users found the dropdown to turn on Forecasting unintuitive, as it was hidden in the more options menu.


Second Iteration

Second iteration of Data Forecasting

After I completed my first round of testing, I then started working on the second iteration. In my second iteration, I added in a quicker way to switch between forecasting, as users found the hidden menu unintuitive. I changed it to a visible dropdown menu on the widget, where users could switch from the normal view to the forecasting view. The other change I made based off of user research was that I changed the table to only show the forecasted values of the selected datapoint.

In addition to the design recommendations generated from research, I added in a full screen view of the forecasted view, in order to remain in parity with the current UI, as every widget needed to be expanded to a full screen view. The one major change that I did make to the full screen view was adding in a toggle that easily allowed a user to go from the default view and forecasted view. Before, a user would have to exit out of the modal, then open up the forecasted view from a hidden menu. In this iteration, all a user would have do was select an option in a dropdown in order to change the views.

Full screen view of Forecasting

Lastly, our UI library had just finished going through a makeover, so I also updated all of the components in the design to match the current library.

Then, I ran another round of user testing with five different users in order to ensure that the design changes did not detract from the experience of the product. I had them complete the same tasks as before, with the additional task of going into a full screen view. All users were able to complete all the tasks, noting that the ability to switch from the default view to the forecasted view was easier than in the current implementation.


Final Touches

After this second round of user research, I then reviewed this design with the engineers. The process was overall pretty smooth, with little to no changes. The only major change that I had to make was to change the full screen view from a modal to a full page view. The reason why I had to change it was based on an overall shift from modals to full page views My team had tested a full page view of the default view and had found that users had no problems with having the full screen view on a page instead of a modal. They found that the modal was taking up most of the page anyways, so it made more sense to just have it as a full page.

Once I finished making this final change, I finished up the engineering review and sent the final design and specifications to the engineering team.


What’s Next?

Right now, alongside the rest of the features in the Resources page, this feature is in Beta at the moment. My team is in the process of gathering post-Beta feedback from customers at the moment.