rachel.s.pope

The Problem

45% of clients visited the dashboard builder but only 5% actually built a dashboard.

Why? Because what they saw was a blank page. They didn’t know what to do next and there was no context to help them. Their most common response was to call their product advisor to ask for a custom dashboard, but that took time and resources away from other clients. Our data showed clients were willing to create dashboards themselves. They just didn’t know how.

Discovery

Competitive analysis & stakeholder workshops.

I created a matrix of features found in popular dashboard builders and compared that to our existing tool, noting where we fell short or where we might have a competitive advantage. I also did a heuristic audit of the existing tool to identify other opportunities for improvement.

I then met with engineering and stakeholders as a group to discuss pain points, client-requested features, advisor-requested features, and overall usability, and discussed these in terms of the personas I had created for the suite of applications.

Competitive analysis
Heuristic analysis

Initial Design

Wireframes using templates and/or a wizard to make the process easier.

From my competitive analysis and experience with other dashboard builders, I knew that templates were very common and sometimes required, and that having that template to drag and drop into would help users begin a new dashboard.

The product owners and SMEs wanted a wizard that would walk users through the process step-by-step to remove any cognitive overload.

Dashboard template
Wizard

Challenges

Limiting factors led to a change in goals.

Access: My position 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 to an over-reliance on this group when creating preliminary designs.

Timeline: There was no clear end date in mind when the project started, but when I shared my initial work with the larger group, the CTO stated he wanted this tool to be ready to show at the company's annual conference for clients, which was only a couple months away. He did not want to show a prototype and we did not have time to build out all the features we wanted.

Shifting priorities: When determining our MVP, it became clear that development leadership and the product owners were not in agreement. The CTO wanted 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. Ultimately, due to time constraints and lack of development resources, we agreed to create an MVP geared toward advisors.

Redesign

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. There was additional discussions with engineering around features and what was feasible, and additional edits were made. This included removing the templating feature since there wasn't enough time to build it out.

Because the long-term goal was still to encourage clients to try the tool for themselves, the MVP design focused on making each page more intuitive and included a stepped navigation to make the steps clearer.

Iterations
Dashboard Builder
Component Overlay

Results

Over 50% reduction in time to create a dashboard. 20% increase in customer user.

The dashboard builder redesign was initially launched with one product (5Maps) for client and advisor testing. Initial client feedback at the conference and to advisors was positive, and client use increased, especially after additional training. Further iterations focused on making the product more aligned with competitors were planned.