top of page

Dash Studio Dashboard Editor

  • Writer: Eric Wienke
    Eric Wienke
  • May 23, 2024
  • 8 min read

Next-generation dashboard visualization, authoring, and content management framework


ree

My Role

Initially, Lead Designer

Later, Team Lead (3 Designers)

Coordinated with PM, Engg Lead, User Researcher, Sales Enablement, and Professional Services


Background

When I joined AppDynamics, the most used part of the entire product was also one of the oldest: custom dashboards. It was created early on, without designers and little customer input. Custom dashboards allowed customers to create their own dashboards using most of the data available in AppD. That way they could decide exactly which data to look at, and the resulting dashboards were frequently used in Network Operation Centers where they would be displayed on large monitors.


The existing product was built on outdated absolute positioning systems that were brittle and difficult to edit. Even so, Custom Dashboards represented over 70% of the day-to-day page views across all of AppDynamics, with over 100,000 new dashboards created each year. They were too critical to ignore.


It was notoriously difficult to make dashboards because it was a very time-consuming process with a lot of repetitive work. Over the years, we received a lot of customer feedback, bug reports, and change requests, but previous efforts all failed to make it to market.


Objective

Design an end-to-end, next-generation dashboard visualization, authoring, and content management framework that is

  • Easy to build, so users can quickly extract value from the product

  • Easy to explore, so users would use dashboards as a jumping-off point for data exploration, spend more time in the product (as opposed to exporting data and using third-party tools), and customers are more likely to expand and renew.

  • Easy to reuse, so we can leverage and extend the dashboard framework in the rest of the product


Issues

The editor was outdated and very brittle, making it hard to achieve the desired layouts. A complex dashboard could take hours and hours and an academic degree to build. One power user said it took him 28 hours to build one of his team's most critical dashboards!


It was not possible to switch the data context, i.e., from one entity to another, so customers would copy and paste dashboards to change one little thing.


This resulted in some customers having thousands of dashboards, and there was no way to organize them - they would all appear alphabetically in a flat list.


It had two modes, Grid and Absolute, which you had to decide on as the first step in creating a new dashboard. The responsive grid mode was barely usable, and the charts wouldn’t make proper use of the available space, so most customers would resort to absolutely positioning their charts on a fixed-size canvas, meaning they had to decide on the resolution they wanted to look at beforehand.


For advanced use cases, users would have to edit a JSON file manually. That was so hard that many customers preferred to engage with customer support engineers to let them create dashboards for them. A whole cottage industry of third-party tools evolved to address some of the shortcomings. It was good business for the Professional Services team but bad for the business overall as customers were drawn to alternative solutions.


Screenshot of a dashboard created with the old editor
This dashboard took someone over 60 hours to build in the old editor, and it doesn't even look good.

Output

  • The information architecture underlying every dashboard built with the editor

  • A set of completely redesigned widgets and data visualizations, replacing the dated and incomplete widgets in the product

  • The design of a state-of-the-art professional editing environment that simplifies creating dashboards at every step

  • A flexible data templating model to bind data to widgets once and repeat many times over - in the same or another dashboard

  • A dashboard organization system involving folders, tags, and screenshots for easy dashboard management

  • An innovative layout mechanism, where the underlying grid re-creates itself every time the dashboard is modified, either by adding new widgets or moving or resizing them on the dashboard

  • A new responsive layout system that would eliminate the need for the existing absolute layout mode


Impact

  • Dash Studio launched as a beta (”Preview Mode”) after about 8 months of development.

  • Within the first three weeks, over 35% of AppD customers had built dashboards in the new tool.

  • Users found Dash Studio to be a big improvement, praising its ease of use and modern look and feel. 

  • Dash Studio and the new widgets became foundational elements for AppDynamics Cloud, the next-generation product launched in 2022. This is now part of the Cisco FSO Platform


Dash Studio makes it super easy to build dashboards. I've got some folks using it and they won't go back to the old way.

DevOps Manager, Security Startup


Dash Studio simplifies management for an IT staff already under tremendous pressure.

Research Director, Network Analytics at IDC


Process

Discovery & Definition

I talked with many customers, both with a PM and solo


I conducted a competitive analysis of direct competitors (Dynatrace, New Relic) and specialized dashboarding tools like Grafana and Tableau. I also took inspiration from other tools people are familiar with for creating layouts, like PowerPoint, Keynote, Photoshop, and diagram tools like Miro and Mural.


In the early days there was spotty PM support. Because there wasn't a complete list of requirements, I had to help identify them.


I wanted to establish a “Minimum Lovable Product” (MLP) that would do the most important things for users while feeding a longer-term roadmap. After we did get full-time PM support, we settled on three main priorities for the initial release within 6-9 months.


  1. Dashboard authoring and responsive layouts to greatly reduce the time to value and improve satisfaction. We needed an elegant data-binding experience that allowed users to create dashboards in minutes.

  2. Beautiful, powerful out-of-the-box data visualizations. Our new widgets must address a wide range of use cases, scale to large datasets with excellent performance, and look beautiful on any screen.

  3. Specialized use cases for collaboration and comparisons. These included much simpler dashboard sharing and comparing datasets for critical business events, such as Black Friday for retail customers.


Requirements gathering

I teamed up with a customer who was struggling with the existing solution. Together, we imagined how the "ideal" dashboard would look, addressing their use cases without taking into account any restraints brought about by the authoring system.


I would then work backward from the resulting dashboard to identify requirements for the authoring experience. Some new requirements identified were the need for multiple pages and within-dashboard interactions like a master/detail view. We also needed new widget types.


ree
Sample dashboard with loading animations highlighting features the new editor should support

Execution

  • Iterative design process: ideation and validation

  • Early prototypes, run by customers and internal dogfooding team

  • Frequent check-ins with Engg and re-prioritization

  • Future-proof designs in stages: presented vision early

  • Created backlog stories


Highlights

Information Architecture


ree
Dashboard hierarchy illustration

The initial design of the information architecture came from the requirements derived from the "ideal" dashboard designed earlier. We needed an IA that allowed for modularity, meaning we could take elements from one dashboard and pluck them into the same or a different dashboard.


One of the critical decisions early on was to utilize the concept of a page and make it a mandatory building block of a dashboard. Every dashboard would consist of at least one page, and once a second page is added, it would show as tabs. That would allow us to take a page from one dashboard and reuse it in another. It would also allow us to create predefined templates as individual pages that users could add to their dashboards.


Because multiple tabs of pages weren't planned for the MVP, Engineering initially devised a different architecture without the concept of a page. Instead, the widgets would be placed directly in a dashboard container. I successfully resisted that design and argued that using pages right away, even if we don't visualize them in the UI, was crucial for future extensibility.


Widgets


ree
Time Series widget with Baseline, Standard Deviation, Navigator, and Health Status

My team and I also designed a set of new data visualizations specifically for the major use cases in the product. Our existing widgets were not particularly visually appealing, didn't behave properly responsively, and didn't address all the required use cases.


From a business perspective, Engineering decided that using Highcharts as the underlying visualization library was the most prudent choice, but I could expand beyond what the library allows where necessary. With that in mind, we designed the new widgets on top of the Highcharts library as much as possible. I occasionally created prototypes for visualizations to demonstrate they could be built in Highcharts.


The result was a visually attractive, fully responsive, internally consistent, and feature-rich set of widgets that the team continues to extend to this day.


Editor



The editing experience went through many iterations with constant feedback from customers and internal stakeholders.


It's a professional tool with great attention to detail, such as snap-to-fit guides, extensive property editing capabilities, and drag-and-drop and edit-in-place interactions. It also supports multi-widget editing, widget alignment, grouping, and z-order stacking and manipulation.


One of the guiding principles was to remove the need for dialogs so widgets can be added, manipulated, and linked to data without leaving or obscuring the canvas.


Widgets can use the global time range or a custom one, and a user can choose from a variety of drill-down options for a widget. Switching between edit and view modes is straightforward, and dashboards can be shared with authenticated internal and external users.


Data Binding & Variables


ree
Specs for the data-binding panel

The data-binding experience was a critical element in the overall design. User research revealed the process was particularly complicated and convoluted in the existing product and was ripe for streamlining and innovation. The key considerations going into the design were


  • Users should be able to see live results as they configure the data. I wanted to eliminate any dialogs obstructing the dashboard's view and taking users out of their flow.

  • Reduce the number of clicks required to get data in the widget. I wanted to provide an experience that is easy to use with the keyboard without ever having to move the hands back to the mouse.

  • Match the user's mental model, not the architecture. The old experience was hard to understand unless users were highly familiar with the underlying data model. I wanted to present a UI that lets people ask the questions as they understand them. It hides the underlying complexity by making inferences based on the user's selections.

  • Minimize the time to go from a blank dashboard to show data. That includes starting with reasonable defaults, editing content in place wherever possible, and making assumptions about user intent.



ree
Data variables allow for quick context switching

One key new feature was the introduction of variables, allowing users to create placeholders for entities that would be evaluated later. Users can create variables for the most common entity types, such as Applications or Tiers, and bind them to an optional default value. The actual value could be changed at any time, allowing the user to switch between all their Applications easily and automatically point to the correct data. This eliminates the need to create many variations of the same dashboard.


Responsive Layout Modes


ree

To address one of the issues users faced in the old editor when using an absolute layout with fixed dimensions, we introduced a different mode to replace absolute layouts: Fixed Aspect Ratio. When that mode is selected, the dashboard behaves more like a PowerPoint slide in that the content resizes to fill as much of the screen as possible while maintaining its aspect ratio.


This mode can also be changed at any time, unlike in the old editor, where that selection had to be made upfront.


The fixed aspect ratio mode retained the desirable aspects of the absolute mode (images won't distort, overlapping widgets maintain their relative position to each other), ensuring the layout never breaks while optimizing the display for all screen sizes. That makes the dashboards much more useful for use in network operation centers (NOC), where dashboards are displayed on a variety of different screens with different resolutions.


Lessons Learned

There had been several abandoned tries before. This one stuck because

  • We constantly validated designs and prototypes with key stakeholders

  • Early focus on flexibility, extensibility, and scalability meant we weren't building ourselves into a corner that's hard to pivot from

  • It's easier to get investment if positioned as a future-proof framework, allowing multiple teams to work on it

  • It's imperative to design in stages and make sure everybody knows the North Star

  • Early involvement in engineering decisions like IA is crucial

© 2024 by Eric Wienke

  • White LinkedIn Icon
  • Medium
  • Flickr / 500px
bottom of page