Goal: 

Create an interactive dashboard that allows customers to easily filter and read about features based on product or version.

My role:

I created questions for customer interviews and surveys at different stages of the process, then reviewed and organized their input. I also gave feedback on text and navigation elements of the dashboard.

Results:

• The team conducted 5 interviews, got feedback from 50 beta testers and demoed the dashboard to several user groups.

• Verbatim feedback on the public dashboard included:

Before:

There was no authoritative source for customers to see how features changed from release to release, which would inform their choice of product version to upgrade to.

Customers were not upgrading at the cadence the business expected. There is an increased risk of issues when they do upgrade late (in terms of security issues, technical disconnects, down time, etc.) 

After:

The team published the dashboard on Tableau Public and shared it across various Marketing channels. To date, the dashboard has been viewed more than 31,000 times.  

Process:

During a hackathon, a technical writer decided to manually export the list of new features posted on the website and present them in a more visual, interactive way. 

Before launching the visualization publicly, she wanted to vet the idea with customers and better understand the information and format they’d like to see. She brought a cross-functional team together to do the research, iteration, and launch. This included team members from Development, Marketing, and me.

I started with feedback on the information hierarchy, labels, and text in the first iteration of the visualization. Some of the points I raised included:

• Intuitively, users might expect the most recent product version to appear at the top of the dropdown list, so they wouldn’t have to scroll past older versions.

• It’s not clear from the dashboard what the color choices indicate – if they mean something, there should be a legend.

• White text on dark backgrounds can be harder to read; make sure the contrast is strong enough to be accessible.

• Where are users expected to go after viewing the dashboard? If they are opening up documentation to read more details on the new features, where do they go next? Can we avoid dead ends?

When it came time to meet and interview customers, I wrote questions related to the content experience and navigation. Sample questions included:

1. Did the story points show the views you expected? Would you remove any? Would you add any?

2. Were you able to find the features you were looking for using the search bar?

3. Where on the website would you expect to find the Release Navigator dashboard?

4. Where would you go if you couldn’t find what you needed?

We used similar questions when we opened up the dashboard for beta testers, but added several others too. After the testing ended, I analyzed the feedback based on sentiment and affinity mapping.  

The next step was to redesign the dashboard based on the feedback. This time, we’d be working with a UX designer. I wrote the design brief, listing out scope, user goal, and top tasks they would expect to complete. For example, the fourth task on the list was:

My last content-related contribution to the project was reviewing copy for marketing messaging around the launch!

What I’d do differently:

At times it felt like we approached the project backwards, designing something and then seeking feedback, rather than designing based on the feedback (what I’d consider to be overemphasizing the solution before being clear on the user need or pain points). We had to go back to the drawing board a few times, but the second hackathon provided an opportunity to reassess design choices and solve the same problems in new or different ways. 

The whole team was pleased to see this video by a Tableau Visionary describing the Release Navigator and why it’s a valuable tool.