A Data-Driven Path to Navigating a Product Redesign

Home/Design Thinking/A Data-Driven Path to Navigating a Product Redesign

A Data-Driven Path to Navigating a Product Redesign

Note from Coworks: We are big fans of Yesware (a sales acceleration tool for closing deals) and constantly use the tool in our own work.

We noticed that the company recently launched a major overhaul of it’s core product and were wondering ‘what’s the main driver for this change?’

Here is the response that we received from Rui Jiang, Interaction Designer at Yesware:


At Yesware, we have a design process that relies heavily on data and experimentation. With over 400,000 registered users, the product team is constantly juggling the needs of both our large pool of existing users (who are reluctant to try anything which interrupts their workflow) and the feature needs of our evolving product (which often require changing workflows).

While it is impossible to satisfy the demands of both masters all the time, a data-driven experimental process gives us the ability to make informed decisions without surprising our main audience unnecessarily.

Below, I’ve outlined Yesware’s design process and how it applies to our recent decision to change the position of our most-used feature: the Gmail dashboard.

The Inbox Dashboard

Yesware has a user interface-first design methodology. Since our product caters to the end user, it makes sense to start from the user interface and work our way down to the underlying data model. In order to reduce the risk of building a bad product, a significant amount of design work is done up-front in the form of sketch mockups, minimally clickable prototypes, and full-blown interactive prototypes.

The inbox dashboard, a kind of “heads-up display” for our email tracking in Gmail, is our most widely used interface. But despite its popularity, users reported a handful of limitations:

1. They had to navigate to the inbox view in order to view their tracking events.

2. It did not support the use case of cross-referencing email content with tracking data.

3. The interface did not provide ample space to accommodate extra functionality (like links to Mail Merge)

As regular users of Yesware ourselves, we knew what we wanted out of the dashboard. But it was not clear whether others having the same problem.

The Interactive Experiment

Changing an interface, especially a popular one with hundreds of thousands of users, is inherently risky. But being big does not excuse us from the necessity of evolving. It just has to be done in a measured way.

Enter experiments. An experiment is an interactive prototype written in actual code, meant to provide learning as quickly as possible. At Yesware, we have relationships with many customers who want to be on the bleeding edge of development. They want the latest feature ASAP, and are willing to tolerate the occasional bug and provide detailed feedback in exchange for early access. While some say that a piece of software caters to early adopters only during its conception phase, we believe that there are early adopters all the time — you just have to find them.

Experiments also provide learning without upsetting the larger audience. If you roll out a feature to 100% of users only to find that it breaks a crucial workflow, you’ve cost the company a lot of time and money. It is best to break the feature for a few users and iterate quickly to resolve any issues.

The Dashboard Positioning Experiment

We ran an experiment on the inbox dashboard, starting on the last week of April. In order to make the dashboard omnipresent across all of Gmail’s views, we pinned it to the top, just below the search container. In order to limit the number of variables tested, we changed very little about the visual design.

We then exposed the change to 1% of our user base and collected both subjective and usage-based feedback. The most dramatic results were gathered off of the usage for our most popular interaction: clicking on the Events tab to expand the dashboard.

There was a 30% bump in the number of users who performed the action as compared with what we’d expect from 1% of the audience. We saw a similar, though not quite as dramatic, increase in the total number of actions.

Real-Life Results

These usage-based results, along with positive subjective feedback (gathered through Google Form Surveys) gave us our answer: the new dashboard position was a success.

In the last week of April, we began pushing out the dashboard to the larger user base. Minor UI bugs notwithstanding, the rollout went smoothly. We continued to track usage carefully over the next few days. Below are some results.

The Events-Tab interaction which performed so well in experiments continued to perform well in production. From the start of our experiment to yesterday, our overall usage increased 18.4%. Even taking into account natural growth from new users, that is a dramatic bump from a single user interface tweak.

The Takeaway

With enthusiastic coders on your team, quickly building features can seem easy. But it is rarely the best course of action. Rush-jobs will only end up costing your company valuable time in the long run. Spending a week or two running experiments is a worthwhile investment that could save you from wasting months building the wrong feature.

At Yesware, data-driven results are a big part of how we believe sales organizations should operate. And we think product teams should work the same way. In the coming months, we will be running many more experiments, so stay tuned.

Rui Jiang is the Interaction Designer at Yesware, a SaaS company focused on accelerating the deals process for sales professionals. To try Yesware’s Gmail Extension for email tracking and templates, visit yesware.com.

By | 2017-05-09T05:31:49+00:00 May 9th, 2017|Design Thinking|0 Comments

About the Author:

Leave A Comment