BIG-IP Dashboard Refactor and Redesign

An inflexible product with a troubled development past, outdated visuals and interaction patterns, and an inability to integrate with the rest of the product was in major need of both a technology and visual update. The green light was finally given only when Adobe announced end-of-life for Flash.

My Role

I led and coordinated all facets of the redesign from start to finish, including: project scoping, requirements gathering, technology analysis, information architecture, user task flows, interaction flows, prototyping, and development. I also conducted user research using methods such as interviews, surveys, focus groups, and participatory design in order to address both user behavior and attitudes.

As the principal designer it was my responsibility to provide the initial wireframes and broad-stroke composition of the design. These patterns were to be the first step in rationalizing the feasibility of a planned redesign of the product’s graphical user interface. I then oversaw junior designers through the process of designing the atomic design elements and layout flows.

The Problem

An existing dashboard developed in Flash had existed in the product for some time, exhibiting multiple design and development challenges:

  • An outdated LnF
  • Adobe Flash - EOL 2020
  • Difficult to extend programmatically
  • No cross page integration (point to another page, or point within the dashboard; can't embed dashboard widgets elsewhere)
  • Design has not visual rhythm; no grid system

The Process

Starting with Dashboard our design efforts started to shift away from single application design and towards common reusable components and patterns that make up a larger consistent product wide experience. We were no longer designing within a bubble – both technology and design decisions had impacts outside our current product scope.

Focusing on the current project while designing reusable components for the larger product scope was our first official implementation of the Fleet Design System.

Technology Evaluation

Working closely with the development team we first started with a technology evaluation, as this would partially impact certain design decisions. At the time of starting our technology evaluation AngularJS was still the primary JavaScript framework in use, with Angular (v2.x) slowly starting to take hold. AngularJS had been previously evaluated for multiple other projects, making the decision to maintain AngularJS as a framework of choice straight forward. The charting technology we decided to select was our primary focus. It was not only important to find an easy-to-use and performant charting library for the current Dashboard project, but one that would be appropriate for reuse within a product wide design system.

Chart Requirements

A short time into the technology evaluation we were able to start developing the chart requirements. Because we were seeking feature parity, we were able to quickly define broad stroke requirements that were needed to match up with existing capabilities. As the technologies we would have available to use became more clear, more detailed definitions were possible.

Design Iterations

Our design goals for the first iteration was scoped around feature parity with the currently available dashboard; available chart types and functionality were to remain feature consistent.

Performance Testing

At regular intervals the design team was involved in the permanence testing of the new dashboard framework and chart components. Working with target user groups we created both expected chart configurations, as well as stress configurations meant to be beyond

The Result

Our primary focus was on replacing the Flash technology, but the process allowed us to further validate new design patterns being implimented as part of the Fleet Design System.

Charts were designed as reusable components that could be designed into pages and usage patterns other than the dashboard. Our goal with the reusable chart components was for other teams to have easy access to ready-made components, but we took the idea that other development teams may need to redevelop charts using different frameworks or charting library.

Next Steps

The immediate next steps to our dashboard redesign was to support additional groups wanting to integrate with the new framework. Almost immediately group saw the advantages to the new design structure.