Customizable Dashboard Framework Design — Step by Step

For Rubrik, a company helping organizations achieve business resilience against cyberattacks, malicious insiders, and operational disruptions, the visualization of data is a critical tool for enabling our customers.

Dashboards are great. That said, giving the user the ability to customize and tailor the data based on what they want to see and how they want to see it, is critical.

But how do you do it right? What should be the guiding principles? How do you find the perfect balance between simplicity and flexibility on one hand and preventing too much flexibility on the other hand? How do you make it scalable? How do you make the experience effortless?

In this article, I would like to give a few insights and guidelines based on our recent experience creating a new customizable dashboard.

First step: Focus yourself!

When looking at such an endeavor, at its preliminary stages, it is easy to get lost in the demands and limitations that must be considered. Therefore, despite the temptation to immediately start designing and laying out things on the page, first we need to answer the basic questions:

• What are our goals and what are the users’ needs?
• Who is the end user?
• When will they use this feature?
• How would we stack rank the features from an end user’s perspective?
• What added value will the user get compared to the existing dashboard? After all, the data is already presented in a clear and organized fashion.

From the research that we conducted we understood that the need for customization consists of the following elements:

1. Enabling the organization of the relevant data according to its importance within the given dashboard.

2. Enabling the freedom to change the representation form in accordance with the type of data.

3. Enabling the collection of various data from different dashboards into one dashboard.

4. The user interface needs to support two cases of customization:
a. Editing and adapting the existing dashboard.
b. Creating a new dashboard from scratch.

5. Customizing features should be easily accessible and discoverable but should not obscure the view.

6. WYSIWYG - What you see is what you get.

7. A clear grid that will clean up the final look and feel, even if a user abuses the layout.

8. A bank of widgets that is small but applicable in different situations for maximizing engineering efficiency.

9. Component size flexibility for maximum efficiency.

Now that we have a clear focused understanding of what we want, it’s time to address the how?

Second step: Translating requirements to design!

When we started work on the dashboard customization feature, Rubrik’s system consisted of 6 different dashboards that had been created over the years. Each one of them included several unique widgets that were designed and programmed for that particular dashboard. There was a total of 20 widgets.

Deconstruction

The next step was to standardize all the widget components into consistent building blocks, with compatible appearances and sizes, so they would all play well together. So, at this point, the existing dashboards were deconstructed.

The grid

Based on the 6 dashboards and their numerous widgets, we established a horizontal and vertical grid that could map the widgets’ presentations which had internal titles, external titles, or no titles at all, which were vertical, and which were horizontal. We created a grid system that worked well with all of them. 24 horizontal pages and up to 18 vertical lines without scrolling where the number of lines is adjusted according to the layout and height of the page’s masthead.

Afterward, we adjusted the 20 existing widgets to the new grid, using the resolution most common among our users — 1920x1080. As expected, this step enhanced the visual clarity of the existing dashboards and provided a strong base from which to develop the logical process of the customization.

Size matters

Next, we analyzed the different sizes and layouts of the various widgets to find patterns that could guide us with future widgets. We looked for the ways the size of the widget influenced the layout of the widget. That way we could compose an organized matrix for building future dashboards that ensures their legibility.

The result was 9 widths with 4 heights for each widget — a total of 36 size combinations for the existing and future widgets. Data responsiveness was achieved by adapting each to the 4 most common resolutions among our users.

This process required significant adaptations of the infographics in the various widgets while ensuring the accessibility and legibility of the data. For example, at small widget sizes, the size of the infographics took priority over the legend. However, at larger widget sizes, the infographics are easily legible, so priority is given to a more detailed legend, granting the user a wider view.

For each widget, we established 4 size categories:

1. Default size

2. The optimal size (recommended)

3. Fair size (additional sizes for customization)

4. Alternative size (sizes for system auto alignment)

Now that we had established the building blocks for the dashboard, it was time to deal with the user interface itself.

User interface

As I mentioned earlier, based on our customer survey, the user interface needs to support two cases of customization:

1. Editing and adapting the existing dashboard

2. Creating a new dashboard from scratch

In both cases, our main consideration was maximizing the availability of the workspace while keeping the options for editing the widgets available. With this in mind, we updated the regular masthead to a narrower masthead, geared toward customization. The masthead space was dedicated to presenting basic actions; for example, save, exit, undo/redo, restore to default, and others.

With the side panel for managing the component library, users could “drag and drop” the relevant widget from the library to the canvas dashboard. We designed the panel as a tray that opens from the left side of the screen by hovering the cursor on the heat zone and collapse back once the user drags the widget out. This way we kept the workspace canvas clear and constantly show the user the dashboard that is being built.

Easy discoverability

In order to make each widget recognizable while still in the library, each widget has a preview that appears when the cursor hovers over it. This effective visual tool makes the experience of building a dashboard smoother and more intuitive.

At the next stage, we had to ensure that the whole user interface was intuitive as well. The idea was a “self-explainable” process where every step in the process unfolds the next options to the user.

For example, dragging the widget from the library presents to the user on the canvas the 3 optimal sizes for the chosen widget. Immediately afterward, the user is presented with possible locations for additional widgets. Hovering the cursor on the sides of the widget will visually present to the user the options for changing the widget’s size, and so on and so forth.

Testing with users

After consolidating the high-fidelity design, we conducted user testing–11 Sessions, 2 Internal Stakeholders & 9 Customers–to see if our hypotheses matched the users’ expectations. The results were encouraging with a final SUS Score 88.9/100 — a good score with little room for improvement — even in cases when users expressed a preference for a different mode of operation. That’s what user testing is for.

Last step, The handoff

You might get the impression that the work of the product design team ends here. In reality, that is far from the truth.

When the developers implement the design, this is when endless ping-pong discussions take place over every fine detail. This is wonderful! Healthy communication with the development team is essential to fine-tune the workings of the interface for the end user and maturing the design.

There are many ways to guide developers and minimize uncertainty, guesses, and questions. The complexity of the task at hand raises special challenges at this stage. Therefore, we tried to anticipate gray areas and answer questions before they were even asked. We provided visual demonstrations of the interface workings and tried to cover every aspect of the customization process from the user’s viewpoint.

In the end, it was fantastic. The development team implemented phase 1 of the project professionally and with great precision.

What’s next?

As always, there are things to improve and refine: gather actual system user usage, survey the users and understand if all our grand plans translated for a better experience, and of course start planning for the next release.