Building dashboarding tools remains a challenging design problem in data visualization and BI products. DataPad aimed to build a dashboarding tool to allow users to create a self-updating, shareable collection of charts. In less than three weeks, I had researched, designed, and created prototypes to serve as the foundation for DataPad's flexible dashboarding tool.


As the design team, I conducted initial research on existing tools, explored divergent ideas through sketches, and prototyped key concepts via InVision. I was also responsible for collecting feedback both internally and externally for design concepts before and during implementation.


Our most basic goal involved helping users put together a collection of analyses. More specifically, how do we build a responsive (i.e. stretching elements with window size) web tool that allowed multiple visual elements to be assembled in various layouts within the same view? My vision for DataPad's dashboarding tool sought to balance intuitiveness with the flexibility of creating custom layouts.

Viewing a SaaS Dashboard. A completed dashboard in view mode allows for filtering and device-type preview.

The Initial Prototype Used Preset Layout Templates

Initial Prototype (sans design) Using Preset Layout Templates. While somewhat usable, it was unpredictable how charts would be rearranged when the layout type changed.

The very first builds of DataPad's dashboard tool used preset layout templates. Entering an empty dashboard would always default to a single analysis pane. To change layouts, we provided a list of layout previews in the top right. Selecting a layout template would lay out empty panes in the desired configuration. The user could then select the analyses (i.e. charts) they wished to display in the dashboard.

Several key issues came up in this interaction:

  • Adding an analysis wasn't easy. It involves first selecting the dataset to which an analysis belongs to, then looking at small thumbnails and cut off chart titles to select the desired one.
  • Choosing a different template when panes are already populated would result in unpredictable configurations. For instance, there wasn't a good way to go from a 2x2 grid to a 3 column layout without having to (1) prompt the user to remove one pane and (2) rearranging the panes in a meaningful order.
  • Templates only allowed for a finite number of layout configurations.

The "Canvas Grid" Concept Affords Better Resizing

The "Canvas Grid" Dashboard. While extremely flexible and easy to understand, this would place much more burden on the user to move and resize panes to create useful dashboard layouts.

This purely drag, drop, and adjust concept seems the most straightforward. Panes, when dropped, default to a 6x6 pane on the canvas. Users can move and resize panes within the constraints of the grid. For visual designers, this is very similar to turning on "Snap to grid" in your design tools.

While flexible and easy to use, it gets to be cumbersome to create complex layouts. Users would likely have overlapping charts or gaps between charts that they would have to painstakingly fix. We strayed away from this concept and opted for a more calculated concept.

The "Edges" Concept Uses a Docking Model

The "Edges" Docking Model Dashboard. A docking model would help users quickly create layouts without having to manually move and resize.

In the "Edges" concept, each pane is framed by + buttons on each edge. The user can start creating different layouts one of two ways: (1) clicking a button or (2) dragging an analysis onto a button. Doing one of these will split the pane either vertically or horizontally. This allows the user to quickly scale to a fairly complex dashboard all while maintaining a good state throughout the process.

A few drawbacks are inherent in this model. Since each edge button will simply split a pane in half, it becomes difficult, but not impossible to create layouts with odd ratios. A three row layout would require an additional interaction not shown in the above animation. Resizing is another difficulty here — since the edges of each pane are already used as "split me" buttons, the usual method of resizing (i.e. dragging pane edges) is not available. There are ways around these drawbacks, but they do add some additional design cruft. In the end, this concept fares the best for what we were trying to achieve.

Side by Side Comparison.

Early Sketches

Sidebar tray of analyses. Early sketches exploring drag and drop to create dashboards versus using dropdowns.
Managing dashboards in a project

A Dash of Concluding Comments

In our brief research, I had looked at several existing products that tackled this problem in different ways. How did other teams build a responsive (i.e. stretching elements with window size) web tool that allowed multiple visual elements to be assembled in various layouts within the same view?

Some teams, like Chartio, used a fairly flexible system that allowed users to lay elements out on an open canvas before manually adjusting position and size. While this was flexible and easy to understand since it's nearly a direct physical metaphor, we thought it would be more cumbersome than necessary.

We also looked outside of the world of data visualization products and into tools that made it easy to lay visual panes out in the same view and in a variety of layouts. Antetype, a layout-aware interaction design tool that I used heavily at DataPad, allows designers to follow flexbox style layout rules where elements are placed into containers that shrink, stretch, and split relative to browser window size. It was this type of layout, in combination with window docking ideas that led me to the new concept for dashboarding.

Development had begun on the "Edges" design concept that used the docking model just as DataPad Inc. began winding down. Despite how quickly the product team had pushed on this problem, time constraints stopped us from fully implementing these concepts. The prototypes faded, but the idea lives on.

Further Exploration

Additional exploration would have considered integrating valuable pieces from all of the concepts. Templates may have been possible to include in either model. At the conclusion of DataPad, a DataPad project in the app separated analyses from dashboards. This often involved tabbing back and forth between the two. Many of us on the team were curious to see if it was possible to integrate the two views somehow to eliminate tabbing.