Dashboard builder
A modernized dashboard experience to build more complex and powerful data portals.
Project Challenge
The current dashboard experience was built years ago. However, user-created dashboards are by far the most used part of our platform. Many of our most exciting business opportunities are centered around ever more complex and powerful dashboards/data portals like the Gates-funded RBM Global Malaria Dashboard and existing clients wanted to build similarly complex dashboards and public disclosure portals.
As we look to superpower our dashboard builder experience, we also understand that there were many existing pains with our current dashboard experience.
Involvement
Design research
UX/UI Design
Interaction design
Client
Zenysis
timeline
Jun - Nov 2021
teamates
Quentin - Product Manager
Stephen - Principal Engineer
David - Senior Engineer
Moriah - Senior Engineer
Nina - Engineer
Isabel - Engineer
Kalyani - Engineer
Project Solution
Deliver a thoughtful vNext Dashboard Builder based on all the signal we have observed and collected to date while also developing net new features that our existing clients require for more complex use-cases.
ux challenges
How might we define and deliver a user-centric roadmap that addresses known pains and fulfills future use-cases?
The product team had systematically cataloged users pains and potential solutions over the past few years. However, we were unclear how to value this potential change or whether the pains observed were even comprehensive or accurate.
Artifacts produced during design thinking excercises
understand and ideate
Build your own artifct
We wanted to tease out pains and ideate solutions within the same session. We had a hunch that the pains users identified would not map cleanly to the solutions they wanted. We used this hypothesis to our advantage to create a 'build your own artifact' exercise. It was a creation of our own so we pilot tested first before iterating and conducting with 5 participants from our delivery team. Here's our four step process!
Step 1 - dot vote pains
In order to create alignment, we re-created the following pains in the current dashboard experience. We then asked participants to choose and place their top three pains.
Step 2 - Dote vote solutions
Separately, we presentd a bank of solutions to participants. After ideating on additional opportunities, we asked participants to choose their top 4 solutions.
STEP 3 - MAP AND RATE
This was the fun step -- we wanted to know whether the pain chosen was really the pain they wanted to solve and make sure solutions actually solved a core pain. So we asked participants to map their solutions to the pains they chose in the first step. If a solution did not map to a pain, then it would fall into the unused bucket. Users then had to rate how well the solution resolved the pain.
STEP 4 - reorganize and discuss
The last step was undeniably the most important step. Participants discussed in-depth why they made their mapping choices. The artifact itself was less important than the qualitative feedback provided during this stage of discussion. In some cases, users actually changed and reorganized their choices.
Patterns and results
The exercise directly shaped the two sequential milestones of our roadmap. It was very clear that we first needed to address a core set of layout pains. Participants did not gravitate to new and shiny features that super-powered layout. Instead, for the second phase of work, they were interested in building out data portal functionalities, such as improved navigation and flexible filtering.
product solutions
Improve fundamental behavior
consistent Drag behavior
In the old paradigm, a newly added element was automatically placed on the bottom of the dashboard. In order to create a more seamless experience, users now had the ability to drag elements from the left panel and place them anywhere on the dashboard.
There was one big design problem -- our analytics tool and our dashboard tool needed to use consistent affordances. In our analytics tool, users clicked elements in the left panel to open additional actions. While in our dashboard tool, users clicked the same elements to begin a drag flow.
Analytic tool affordance -- click to open details
Dashboard tool affordance -- click to drag element
In order to account for these two affordances, I had to design a consistent way of using visual metaphors.
Analytics tool
Dashboard tool explorations
Exploration 1 - shadow not a strong enough metaphor
Exploration 1 and final solution - raised and offset element
Space is created
When either moving a tile around the grid or increasing/decreasing the size of a tile, other tiles make space by moving down. Every tile below will automatically adapt and shift down, preserving your structure.
Space is Eliminated
When you delete tiles, your dashboard layout will shift vertically to fill the space automatically. This allows you to restructure elements quickly without disrupting your overall dashboard layout.
Improve structure & Placement
"Why do all our users dashboards look messy, unstructured and unprofessional?"
This was a question that nearly everyone at the company asked. The dashboard tool was one of our mostly used tools. We should create a dashboard layout experience that would allow non-designers to create clean designs.
Focused tile interactions
Misalignment of tiles, unevenly sized tiles, creating structured layouts, and fitting tiles into empty spaces were all among the top pains users experience. In the legacy experience, we did not provide the user enough visual context to effectively create structured and repeatable layouts. In the refreshed experience, we wanted the experience to feel like a systematically fitted puzzle. Paired with our new base behavior where vertical space is eliminated and space is created, users can quickly and accurately resize and align elements.
The following is the interaction system that underpins this feature. There are five states of a tile (Default, Hover, Selected, Resize, Move). For a given tile that a user is interacting with every other tile will receive visual effects as well. So there will effectively be 2x interactive states (one for the tile being focused on & one for the tiles NOT being focused on)
Less granular, more purposeful grid system
Old system
New system
Compare ease of new system to old with coarser grid system and use of 12-column rulers
The legacy grid system used 100 columns and felt overly granular, meaning users needed to be quite precise when sizing or aligning elements on the dashboard. The new focused tile interactions would alleviate some of this problem. So we questioned whether we should maintain the granular grid system or provide a coarse grid system. A granular system would allow us to create a system with optimal spacing and text sizes. However, our users do not have a design background. With a more granular system, users are more likely to create poorly structured and messy dashboards.
The question was -- How granular should we go? It was a question that I couldn't solve purely through a static design tool. I required real feedback. So I paired with an engineer to create a tool that would convert our dashboards given a set of input handlers:
-
Layout handlers -- cells per column, cell size, column count, etc
-
Text handlers -- font size, font weight, line height, paddings
Tool to edit underlying layout and text system in action
After playing with the tool, it was clear that advantages of a coarse grid system heavily outweighed the advantages of a granular system. Sizing and aligning elements using the 24px grid system actually felt pleasant and efficient. Although the composition looked slightly awkward using the 24px grid system, the hierarchy of space and font was maintained well enough. In terms of the text, we could create the right hierarchy using either grid system. The 24px system limited the text options available. However, this was a case of "less is more". Users didn't require a granular text system like Microsoft word. Instead, limiting text options like Medium created a more focused experience, guiding users to create structured layouts with only three header types (title, header 1 and header 2).
24px system
8px system
24px system requires much less precision than 8px
12-column rulers falling on every 4th column further helps create structure
In the conversion from the legacy system to the new system, we needed to create a set of conversion rules since it was impossible to perfectly move from a 100 column based system to a 48 based system. We found that in the legacy system, users were typically trying to create fairly simply layouts using widths of: 100%, 75%, 50%, 25%, and 12.5%. However, given the granularity of the legacy system, users never quite sized elements perfectly (eg. 48% or 52% instead of the intended 50%). We programmatically cleaned and restructured all dashboards.
Prior to conversion process, we researched where tile borders fell. This image shows every dashboard superimposed on one another. The darker the line the more often a tile falls on that part of the grid.
.png)
After the conversion process, we gauged success by counting the times a tile ended on a column.
Better by default
harmonious text system
In the legacy experience, the text system did not adhere to the grid system. Meaning more often than not, a text container would either be too small (ie, cut off the text) or the text container would be too large (ie, have an awkward space that threw off the balance of the composition). In order to make make sure good spacing was maintained by default, our text system followed the mini-unit of the grid system. Whether a user used a large header on a single line or normal body text on multiple lines, the text block would always follow the mini-unit of 24px. Since vertical space was eliminated, the user by default always created a composition with good space and font size hierarchy.
For each different grid system, we created a number of iterations that combined font size, line height and spacing. Coarser grid systems required more creative experimentation since the mini-unit grew by a larger amount. Unlike a platform like Medium in which white space can be used liberally, our product is information dense. So we had to minimize space without losing hierarchy or making the composition look constrained.
Responsive in nature
By default, the dashboard page increases and decreases in size according to the size of the viewport. We tried to optimize for the most common screen resolutions. However, when screen sizes become so small that text legibility fails, the dashboard page becomes fixed. When screen sizes become too large, the dashboard page stops growing in order to maintain information density.
contextual tile sizes
In the legacy experience, every tile regardless of type received the exact same size, ie a giant 4:3 tile. In the new system, each element received a default size that was most appropriate to its intended use. For example, text is full width and autofits to content, a placeholder visualizations represents the most common visualization size so is 75% width with an aspect ratio of 4:3, a table visualization is full width with an aspect ratio of 2:1 while a number visualization is 25% width with an aspect ratio of 1:1, etc.
Milestone 2
Coming soon...