Sprinting Our Way to a New Dashboard

What makes a customer happy? The answer varies depending on the context, of course.

With Ambassador being in the referral marketing space, “happy” for our customers meant logging into their account and seeing the dollars roll in. Except the logging in part was putting a damper on that happiness, despite successful campaigns.

Final MVP Dashboard Layout Our old dashboard

Enter the problem: A neglected dashboard

Once a tool we were proud for customers to use, our dashboard was no longer user friendly. We couldn’t be confident that the data shown to customers, as well as how the data was presented, were a good fit for their evolved needs. Plus, the load time had declined significantly.

It was so slow, in fact, that we had to redirect our customers to the “build” page to avoid suffering the load time. This was not ideal since the typical reason they were logging in was to check the progress of their campaigns, not build more. However, the temporary redirect to a quick-loading page was better than adding friction to their user experience.

We knew our customers were busy people, and they didn’t have time to sit and wait for the page to load—especially the first one!

Putting on our thinking caps

While the main issue was load time, we knew this was an opportunity to identify and address other improvements in the dashboard. We faced several dilemmas in taking on this redesign initiative:

  • How do we offer our customers helpful information without bombarding them with too many (and unhelpful) features or making the page sluggish again?
  • How do we ensure our customers receive the most value from the dashboard without taking an exhaustive amount of time in the design process?
  • What’s the best approach to take to address these dilemmas?

We used these questions as starting points while keeping this in mind: Our customers deserved the best possible user experience with our product. So, we set out to make that a reality.

Sprinting Our Way to a New Dashboard

Considering the dilemmas we faced, especially the time constraint, we concluded that a design sprint was our best path forward.

We modeled our sprint after Google Ventures’ design sprint, complete with its 5-day agenda. The compressed timeline of the sprint was the primary selling point: Instead of waiting months to build and release a minimum viable product (MVP), we could get real, immediate feedback in just days.

There was also the benefit of building and testing prototypes with real users. That way, we weren’t just designing “with the user in mind,” but gathering direct input and feedback.

The team: Our head of product, one engineer, and two customer success folks joined me (product designer) in the sprint. And while my role in the sprint started out as a producer, it quickly transitioned into a strategist and facilitator (similar to GV’s “Sprint Master”).

The agenda:

  • Monday: Understand & Define
  • Tuesday: Diverge
  • Wednesday: Decide
  • Thursday: Prototype
  • Friday: Validate

Monday: Understand & Define

We began by digging into the problem. This was important for gaining deep awareness of what exactly we needed to solve.

We each provided key pieces of knowledge to focus our efforts. Our head of product informed us on the business opportunity, as well as technical limitations and constraints. In parallel, our CEO expanded on the business and marketing opportunities. For my part, I benchmarked and analyzed several other dashboards in the marketing space and presented my findings to the team.

During this 15-minute brief, everyone recorded notes using a technique called “How might we?” These were questions specifically phrased to inspire creativity and help us find innovative answers. They would come in handy later in the week.

Next, we established that the dashboard needed to accomplish the following:

  • Address root causes of unsuccessful programs
  • Accommodate common workflows
  • Make common questions easy to answer

We also came up with a few guiding principles for the sprint:

  • One right way — There should be one right way to accomplish tasks. Users shouldn’t be able to achieve the same task by going into different places of the app, as this leads to a higher cognitive load.
  • Self-contained — Make the dashboard self-contained. It shouldn’t serve as a place for managing activity or metrics; rather, it should serve as a place to identify issues and show the user how to address them.
  • Reduce clicks — A pretty common theme for most projects; ensure the user has a clear, frictionless path to accomplish tasks with the least amount of effort.
  • Explicit over implicit — Make things explicit. Don’t add UI components that might have an implicit meaning; reassure the user by making everything clear.

The second half of the day consisted of several actions:

  • Creating various “jobs to be done” that describe our product’s users;
  • creating a design principles list—adjectives we wanted our users to describe our product with (i.e., fast, intuitive, helpful, powerful, easy to use); and
  • imagining what our first tweet upon launching the dashboard would look like.

We finished the day by drawing out a complete journey map from when the customer first discovers the new dashboard until they become “super users.”

Tuesday: Diverge

Now that we understood the challenge and defined the strategy, we could start throwing around ideas. For this activity, Google recommends a great technique called “Sketch 8 ideas in 5 min.”

Fairly self-explanatory: Each team member quickly sketches 8 potential UI solutions in 5 minutes. The purpose of this activity is to generate many ways of solving the challenge (whether they’re realistic or not).

A few solution sketches

During this time, I scheduled 3 users to test on Friday (just 2 days away). (According to Jakob Nielsen 5 user interviews would have been ideal, but due to the short notice, 3 was all we could get.) And to streamline the interview process and gain consistency, I also created an interview template to use.

Wednesday: Decide

After sketching the previous day, each of us shared our ideas on the whiteboard. We discussed them, and afterwards, we voted on our favorite solutions. It quickly became clear which solution we would end up using.

These are the key pieces that we decided to include:

  • Help/Callout
  • KPIs
  • Comparison Chart
  • Company Notification Area
  • Global/Worldwide Activity View
  • All Activity Section

Thursday: Prototype

I spent the entire morning, afternoon, and late evening creating a prototype with Sketch and InVision. And thanks to Reactions (our pattern library), I didn’t have to worry much about coming up with new components or styles, giving me more time to collaborate with the team and clarify prototype aspects.

Prototype 1 Prototype based on our solution from the previous day

Friday: Validate

For Friday, I finally had the opportunity to speak directly to the users.

My goal was to make everyone feel comfortable—to let them know that they were encouraged to “think aloud.” For me to get the best insights, I needed them to be as open with me as possible; every thought and feeling was important to express.

Essentially, I asked them questions such as “What’s going through your mind as you look at this?” and told them “If you get confused or don’t understand something, please tell me.”

I went through each of the components, piece by piece, and gathered their feedback. I was a little shorthanded this day, so I ended up asking the questions and taking notes (which is harder than it sounds!).

Prototype 2 Prototype based on findings from user interviews

Sprint Results

One important insight from user interviews concerned date ranges. Previously, we enabled users to choose whatever dates they wanted, which was partly to blame for the long load time. However, it turns out users had no real need for that level of open selection. They only needed 5 choices: Daily, weekly, monthly, quarterly, and yearly.

The remainder of the must-haves included

  • an overview area to surface potential problems and identify areas for improvement;
  • a table where the user could track and compare key metrics over time;
  • a list of key KPIs and their current performance; and
  • a real-time activity feed.

The following Monday, equipped with insights from customers and team input, I created a few potential solutions.

Launching the New Dashboard

Here’s the final MVP layout I delivered:

Final MVP Dashboard Layout

The launch of the dashboard was accomplished by including a link in the header of the old dashboard notifying users of the updates. The user had the ability to go back to the old dashboard by clicking another link in the header.

We knew that the design was drastically different from the existing experience our users were accustomed to, and presenting them with this new experience with no option for returning to the old dashboard could be jarring and lead to drop-offs.

We were extremely happy with what we accomplished in such a short time, and so were our customers. In short, we were able to

  • greatly improve loading time;
  • provide appropriate metrics based on user interest; and
  • remove unnecessary clutter.
Published January 2017