Background

Goals

/ Increase customer NPS
/ Reduce complexity
/ Increase speed of updates

Approach

The data was telling us we had some work to do. We just started using NPS and it was low, our overall usage was at 54%, and our sales team was having some challenges convincing some prospective clients that the software wasn’t complex. But what was causing these symptoms? We needed to connect with customers and understand how they used the product to get the full story. So began ph 1 of this project where Sarah--a designer on my team and I--embarked on some extensive studies in addition to the roadmap work we were already doing. 

We rallied CS to help us identify customers that would be open to having us visit them onsite and see how they were using the product. We visited 18 customers in person in both LA and New York. Not only did we learn about the usability of the product and what features they were more apt to use and why, it led to more fruitful conversations that gave us insights into other areas that had nothing to do with design--like change management, operating mechanics and things that we needed to share with the broader teams. 

We also leveraged other data in our efforts. From a qualitative standpoint, I delved into NPS verbatims to learn what users had to say. I even got on the phone with detractors to find out more about what wasn’t working for them. From a quantitative standpoint, we looked at what the in-app actions reports were telling us as well as the NPS metrics. Lastly, our sales and CS teams were our eyes and ears in the field and we met with them regularly to learn more about any problems or requested features. 

What customers were saying:

“It takes too many clicks to complete important actions.” 

“So much effort navigating in and out of objectives/key results to update them. Would be nice to make updates in one central place without changing pages all the time.”

“Cumbersome to navigate. It's too time consuming.”

So Sarah and I unpacked all of our findings and prioritized our learnings based on customer value, NPS and feasibility (since we wanted to know which changes we could affect quickly). We made several recommendations on how to improve the product which we shared with the head of product and the CEO.

At a high level, users were struggling with navigation, product complexity (in their minds goals should be simple) and the time they were spending in the product to make updates. We were forcing them to go to each Goal Detail page (that’s the page on the bottom right) to make their updates and frankly, it had become cumbersome. The CEO supported our desire to make the experience better so we pursued low hanging fruit that could be knocked out quickly and also prepared to reimagine the goals experience. 

We then moved to phase two--Go Wide, Then Decide--where I worked with our core platform designer and a new PM. The designer and I came up with some basic design principles for this project (we already had our broader set of design principles as a team). These were intentionally granular to make sure that we were addressing customer pain.  

/ Design for efficiency of frequent actions

/ Simplify navigation

/ Surface primary actions and make power user actions accessible through progressive disclosure

/ Eliminate redundant actions

They took the findings and recommendations from our research to do solution brainstorming and prioritize and narrow ideas. A few concepts emerged but we felt most convinced that having the goals experience appear on one page that users never had to leave while balancing the right amount of info to serve up was a promising direction.  

That said, the head of product, was strongly encouraging us to just redesign the goal detail page ONLY and allow users to edit from there. We weren’t convinced that was the right solution b/c—this would not have addressed two main issues which were navigation and time spent in app. so we set out to validate these two ideas in the next phase. 

We then moved on to phase three--Experiment--where I worked with the two designers and the PM.

Our finding pointed to the fact that users preferred the “one page concept” and didn’t feel the need to have a separate goal detail page since that information would be available through progressive disclosure in the one page version as well. 

I pushed for this concept and used our research findings to validate that this was a risk worth taking. After some back and forth, the head of product was on board and the engineers started building. 

3 weeks before Beta launch, Sarah and I did additional testing in our sandbox to make sure that there were no glaring issues. We did find opportunities now that this experience was completely interactive and quickly made recommendations, filed improvements in JIRA and prioritized them with the head of product and engineering so that we could make sure the changes were in for the beta.  Others would have to be ready for the launch. 

Results

The beta launch was 6/13/17:

• Testing NPS ranged between 7 and 9 (sample of 22 customers)

• Beta retention was 75%

Metrics that would be monitored after official launch included: NPS, reduced check in time, and increase in monthly usage. I left the company before getting any updated metrics.