Engineering @ PaperG

Let’s talk about redesigns. As your product matures, you gather more and more user feedback, and you eventually have enough good information to redesign. The update addresses your users’ concerns and presents a more intuitive interface. But too often your changes will draw the ire of your most dedicated users, who learned and grew on your old interface. The new one is strange and uncomfortable, and they want the old one back. Yes, your redesign is better and shinier, but you just annoyed your most loyal user base.

That problem is old news to us. Thousands of people use PaperG’s products for their jobs, and all of them are trained to use our online ad software. When we redesign, we can cost these people valuable time re-learning our “improved” interface, and their time is their company’s money – our customers’ money. If we’re not careful, we lose customers out of frustration and irritation. So we take a step back, and we design the redesign.

Whenever you redesign your product, your users go through “retraining.” They have to figure out the new ways to do things and forget the old ones. They’ll figure out tiny changes quickly, but they need extra help with more substantial changes. For those changes, we design ways to guide users through new interfaces and minimize the pain of retraining – transition strategies.

Transition strategies pose a unique bandwidth problem because they’re temporary features. They’ll be gone in a month, so you don’t want to spend developer time on them. That would waste valuable talent, and we already have a persistent shortage of engineering bandwidth (did I mention that we’re hiring?). Rather than starve important projects, we adapt our strategies to use as little developer time as possible.

Our secret is deceptively simple: we offset most of the work implementing transition and retraining strategies to our support team. In practice, this requires significant planning by the product and support teams. However, after over thirty iterations over several years, we’ve gathered a few favorite strategies that are easy to implement.

Callouts

We often use callouts for small changes, but they only work if used sparingly. We deploy callouts to point out buttons that moved, or new features. Users only see the message once, and they have a choice to view the quick briefing or to just dive in. We’ve been using a service called WalkMe, which lets our support team design the briefings with no help from the developers. We rarely use callouts to explain features because users don’t like to read. Instead, we use them to direct the user’s eyes to changes, and to remove the sense of surprise. This is important enough to repeat: use callouts to point, not to explain.

Tutorial Videos

Unlike callouts, tutorial videos aren’t so great at pointing out changes, but they’re great for explaining new concepts and features. We show the tutorial video the first time a user encounters the updated feature, and the user can always dismiss the popup. Each video takes several hours of our support team’s time, but it takes little of our developers’ time to actually embed the video. As an added benefit, these tutorial videos make excellent training materials for new customers.

Support Articles

People do still read support articles, so we write them. However, we’re careful to avoid writing a manual, because our stats consistently tell us that nobody wants to read more than they have to. We make sure to hit two important requirements:

1. Navigation to the right article needs to be easy and fast. For that, we use contextual support buttons and carefully curate their links to make sure users trust them for the right snippet of useful information.
2. Our articles are short, light on text, and heavy on images. Our users don’t have the time to sift through a manual, so we don’t bother to write one. Instead, our support team writes articles to address the common issues users bring to them.

Once again, our support team does the heavy lifting.

Live Support

Finally, we have live support by phone, email, and chat. This is a safety net that catches every user who wasn’t helped by our other release strategies. Google Apps offers an easy phone and email functionality through Google Voice and Gmail. For live chat, we use a wonderful service called Olark, which only requires our developers to embed a JavaScript tag. The rest is done, once again, by our support team.

I suppose this post turned out to be more about support than engineering, but that’s partly why our release strategies work. As part of support’s job, helping frustrated users, they implement actual site features and free our developers to work on other things. And our support team interacts with users more than the rest of PaperG, so they’re actually the best people to retrain users with each new release.