Dashboard Builder Application

ask

I was asked to take an existing tool that was used internally to build dashboards for clients and improve it so that it could be used more efficiently and would be intuitive enough for clients to use as well. In addition to being modernized, the tool needed to include features that would work for all users in the five separate applications it was included in.

discovery

Image of a spreadsheet matrix of features by competitor
Image of one page of a heuristic analysis with notes

I started with a competitive analysis of existing popular dashboard builders, creating a matrix of features and determining which were available in each product, which settings could be turned on or changed, and which were the default settings, and compared that to the existing tool, which fell short on many levels.

I also completed a heuristic evaluation of the current tool to identify opportunities for improvement.

Image of a simple planning wireframe with elements and notes
Image of a set of user personas

Armed with this information, I met with the stakeholders (the product owners/advisors and the head of development) and discussed pain points, client-requested features, advisor-requested features, and overall usability. We also discussed the types of users who would be using the application, using personas created earlier for the suite of applications, and brainstormed some solutions to the pain points, discussing features that could be built in a reasonable timeframe, as well as solutions that would work for all the products.

design process

Image of a wireframe of a dashboard wizard tool
Image of a wireframe of a template selection tool
To begin, I met with the product owners and SMEs for each product separately to discuss issues unique to their products, as well as what they had heard from clients. Based on these discussions, we thought providing templates and a wizard would encourage users to try the tool and then explore the more advanced features.

setbacks

My position at this company did not allow me direct access to any customers. I had to rely on the product advisors - who spoke with several customers daily - to provide information and to work with customers on testing out potential solutions. This led me to working directly with the advisors and product owners instead of the larger group when doing preliminary designs.

When we reviewed the work with the larger group, it became clear that development leadership and the product owners were not in agreement with what the goal was. The CTO wanted to develop a tool that made it easier for advisors to create dashboards. The product owners wanted a tool that would work primarily for clients, but that advisors could also use when necessary. Ultimately, because the project could not proceed without development resources, we resolved to create the MVP tool initially for advisors as the CTO requested.

redesign

High fidelity wireframe of a dashboard creation page
High fidelity wireframe of a component selection tool
High fidelity wireframe of a dashboard settings page
Focusing the design on advisors rather than clients meant moving away from a wizard and back into a more complex UI. Several rounds of wireframes were produced and reviewed by the whole team for input. When introduced to development, there was additional discussion around features and what was feasible, and additional edits were made.

results

Image of dashboard builder MVP within an application
The dashboard builder redesign was initially launched with one product (5Maps) when that product was redesigned. Initial client feedback was positive and client use has increased, especially after additional training. The intention is to add it to the other products when their redesigns go live.