Wednesday, March 15, 2017

Tear-free App Updates

"Dear @Marriott - please go back to your old app - it worked perfectly.  Get rid of whoever designed the new one - it is awwwwful."
Have you seen those home improvement shows where a team of decorators surprises a family with an made-over house? The results cause more huge frowns, tears, and chaos than you’d expect.

Mom stares catatonically after discovering her Grandmother’s antique dresser holding the bathroom sink. Her hand leaves a fuchsia trail of Krylon on her jeans from the last minute paint job. Dad faints on the avant-garde cardboard lounge chairs replacing his beloved leather reclining couch. The kids roll on the floor and wail at their legos glued to the playroom ceiling.

The viewers marvel at the chaos, wondering what the decorators were thinking.
An amazing new floorplan update
The same shock and disappointment hits customers when a company drastically changes their app:
Dear @Marriott - please go back to your old app - it worked perfectly.  Get rid of whoever designed the new one - it is awwwwful.
Bad app makeovers cause tears, and not just for poor taste. Large updates change how an app works. New features are emphasized and existing features are moved, removed, or altered. Our customers finds themselves stumbling through a new, unfamiliar interface, yanking their hair out, not getting work done.

When customers have trouble using a new version of an app, they don’t see a learning curve, or a beautiful new concept they should give time. They see low quality. They got stuff done on version 2. Version 3 leaves them fumbling like a toddler at nap time.

Customers know that they didn’t wake up dumber. The app changed and now they’re balding and can’t get their work done. The simplest explanation: the app sucks. One star — they’d give zero if they could!
"would give it zero if I could" Google search
We app makers often see quality as a one-dimensional measure. The app crashes, or it doesn’t. A feature works or it fails. Simplistic models of quality work for a while, but mature apps need a wider perspective. Measures of quality must incorporate customer sentiment and behavior. An frequent user of your app might prefer an occasional crash to a setback in usability or functionality. A crash is a temporary glitch; an inability to locate or correctly operate a feature leads to a cascade of hurt.

When users get stuck or make an mistake using an app, recovery is difficult. Who do they call for help? There is no AAA to come jump-start your app or tow it to the nearest app repair shop. App support hotlines are rare. Book stores don’ t sell Dummy’s Guides for your app. As app makers, we must anticipate and prevent customer issues so our users don't redline their frustration gauges.

The Great Skitch Update Debacle

Evernote proudly released Skitch 2.0 for Mac in 2012. It was a big moment for the company. Exciting blog posts. Press coverage. Customers reacted like we burned down their house. They wrote reviews that made us double over and clutch our bellies.
"Loved it before the update"
Internally, we saw Skitch as a visual communication tool. We worked hard on Skitch 2.0 addressing many shortcomings of the original app. We worked long hours fixing quirks and adding useful communications features. From our perspective at Evernote, the features we dropped seemed unimportant and a distraction from what we saw as Skitch’s purpose.
"Horrible downgrade" - when app updates go wrong
But we didn’t understand Skitch’s purpose. Our experienced users ached at the loss of features like FTP and custom fonts. To those customers, the features that went missing were key pieces in how they used Skitch. Skitch wasn’t just a visual communication tool to them. For some, Skitch was a tool for uploading images to their blog or website. Others used Skitch as a simple image editing package. Skitch 2.0 broke those workflows, forcing those users to use a different product.
"This version is a colossal piece of junk"
How could we be so dumb? We didn’t control Skitch’s purpose. We could influence it, but the customers ultimately decide what they use the app for. Our team didn’t understand these customer perspectives until after we ruined their week. Like the interior designers on TV, we made drastic changes while ignorant of how people really lived in our app. Where we saw an ugly couch, our customers saw a cozy place to watch an action flick.

Evernote acquired Skitch in part for the passionate user base. We took great care. We didn't want to upset anyone or turn that passion against us. We sat for long meetings, testing betas, debating the user experience. Developers wrote code late at night, trying to get each feature ready for the big 2.0 debut. We put in so much effort that Skitch 2.0 took longer to release than planned.

Quarters of work, probably man-years of effort, and our customers still recoiled in horror. It doesn't matter how much we debated UX and reworked features. The success of an app lies with the customers, not the executive team, product management or the team building the app. That lesson arrived in an avalanche of 1-star reviews. Ultimately we apologized and promised to return the missing features. Too bad it cost us so much good will.

For the record, things have turned around for Skitch. Skitch 2.8 for the Mac has a five star average review. My Evernote friends have worked hard to make Skitch a world-class app.

More Growth Doesn’t Mean More Churn

Remember Skitch 2.0. Never forget your current customers as you scramble for growth or glory. Your best customers have learned every detail of how your app works, even the quirks and flaws. They’ve become experts in your app, probably even more so than you. Like a carpenter with a hammer, or a mechanic with a box wrench, they use your app without effort. They prize this ability because it gives them an advantage. It makes them productive.

If you alter your app too much, you steal their productivity. Skitch’s choice to remove features fell on the extreme end of the productivity-robbery spectrum, but even a simple reorganization of the app can break workflows. When the app no longer feels familiar, even long-time users fall to a novice skill level. Imagine a mechanic having to concentrate on their box wrench technique, or a carpenter having to relearn their hammer. They’d fall out of the zone, lose their happy thought. A forced return to conscious thought means slowing down. It robs them of productivity and leads to busted knuckles.

Even if your new design will make all users more productive in the long term, your formerly most productive users will grind their teeth. Minor productivity setbacks feel like getting stuck in traffic on the way to a party.

Hopefully customers won’t abandon your app before they return to productivity, because you’ve just created a moment with lower switching costs: “since I have to learn a new app anyhow, I may as well try something new.”

Don’t sacrifice your existing users just to attract new users. Customer growth depends on manageable churn rates, not just higher conversion rates. If you pop the balloon, you lose any gains from adding air faster. A successful app requires customer engagement in all cohorts, not just the tire-kickers drawn in by a pretty window display.

Planning Updates

I wish I could explain how to make everyone like your app updates. That's a fairy tale though. With a large enough user base, you will always have one customer scribing a zinger on the App Store. Some people just love to hate. The best you can do is mitigate customer pain by making conscious tradeoffs.
The Update Journey
Like a family road trip, smoothly updating an app requires planning and staging. You can’t just drive from Florida to California without a break. Adults need to stretch their legs. Kids need stimulation and snacks. Everyone need bio-breaks, to eat food and hydrate. Transforming your app is a journey, for both you and your customers. You need to know your destination, how to get there, and where you can take breaks.

To craft high quality apps, you must orchestrate changes to take customer needs into account. Needs like: don't break my workflow. Or: don't let me get lost in an unfamiliar user interface. Or even: give me feature X. And, of course: don't let anything break.

Every change you make to your app adds a little risk to the proposition. Risk that customers won't be happy. Risk that the app might crash. Risk that customer data is lost. Who knows? Limiting the scope of your updates helps you manage risk. Smaller scopes mean faster updates, less for customers to learn, and the ability to respond quickly to customer feedback. Large updates compound that risk and also inhibit your ability to rapidly respond to customer feedback.

The journey metaphor is not without flaws. As you attempt to reach a beach oasis, you'll be camping in the jungle, climbing mountains, and fording rivers. The app may start to look a bit janky: some new bits of interface are slick and beautiful, while older parts of the app seem worn and tired. There are tradeoffs. Spending 6 months on an update that directly helicopters your users from 1.0 to 2.0 could be the right decision for your business (incidentally, there are more than 2 paths; you can helicopter your business focus to 2.0 while leaving the customers at 1.0).

What do You Want?

Start your update planning with self-knowledge. Why does your team wants to change the app? Are you matching competitor’s offerings? Reducing churn? Attempting to increase the average revenue per user? What results do you want?

If you have multiple goals for an update, prioritize. Pick one thing. Having one goal to per release lets you limit the scope of your changes. Big releases can overwhelm your customers. Spreading out the changes over time helps limit the burden on them. Save your second priority for your second update.

If you worry that your app looks uglier than a hippo’s rear, you can start a makeover without impacting the functionality. You don’t need to change how your app is organized, what vocabulary it uses, or how you make money. Hold those variables constant while you reign in the colors, pick more tasteful fonts, and improve your use of whitespace.

When you users open the re-skinned app, it will look cleaner and more modern, and their muscle memory will still work. Is that just putting lipstick on a hippo? Maybe. But your customers understand lipstick. Makeup is useful -- ask any actor. Customers won’t understand if one update transforms a hippo into a narwhale. People understand an ungainly hippo getting a makeover.

For your following release, maybe your goal is to add a new feature. Again, you keep the change surgical. You add the feature, but keep the appearance of the app, the overall organization of it, and so on. Let that change sink in for a bit before your address how the app is organized, or whatever the next stage of your update might be.
App update smash
If you lose sight of the purpose behind an update, you will go overboard. Without focus, designers, developers, and product managers start to think that they “might as well” add X, Y, Z, and also Ƣ to the release. When you finally ship — and it will probably take a while if you keep glomming on features — your customers won’t recognize the updated app.

You must have the discipline to limit the scope of changes. Otherwise your customers will choke on their grande mochaccino and hurl their phone into the nearest storm drain. Clunk. Clunk. Splash!

After they upset your customers, these bloated releases hurt you again. Mistakes in a bloated release takes longer to fix than a tiny one, don't they? Bigger changes also make it more difficult to untangle the feedback you get. Return your gaze to the tweet about Marriott above. Can you tell what went wrong?

How Will Your Customers React?

Great updates require empathy. You can't make good decisions for your customers without knowing how and why they use your app. Some companies use customer personas to help them empathize with each kind of customer. They give their personas names, and sometimes even mascots (e.g. stuffed animals).

You might feel too shy to name your customer personas (Bobby the Ballerina!), but you should keep in mind how different categories of customer have different needs, workflows, and expectations. Your most active customers almost certainly have worn a path through your app. Know what those paths are. Customers won't smile if you obliterate their favorite path with a taco stand. Thanks for the tacos, but how do I get to the FTP feature?

Discovering your customer taxonomy will take some research if you don't already know. There are many tools to help you understand your customers: analytics, customer reviews, and other tools like Jobs to be Done interviews. Your app exists to serve customers. You better understand who they are!

In addition to personas, there are different stages of the customer lifecycle. For instance, most apps have both new and existing customers. A new customer can have a completely different reaction from someone familiar with your app. While you don't want to upset your best customers, you also don't want your new ones to bounce right out of your app and delete it!

Systematic Empathy

Once you know the different kind of customers you have, you can examine each change through their eyes. Make a spreadsheet of your customer taxonomy so your empathy rays don't miss anyone.
Customer Persona Empathy Chart
Here is one way to think about it. For each customer persona, add a column to indicate if a proposed change would go unnoticed by that kind of customer. For each persona who might notice the change, fill out a column indicate if they will be helped in the short term, helped in the long term, or hurt by the change. Add a final column where you will document your strategy to smooth the transition for this customer. If any of those strategies don’t seem trivial, that’s a sign that your update has grown too large. Consider breaking the update down into a chain of smaller updates.

Pro tip: you're allowed to talk to anyone. Test the assumptions in your spreadsheet with conversations, beta tests, and demonstrations! Even if you're speaking one-on-one with customers regularly, never forget to look at the reality of your releases. Analytics and reviews are real feedback from a broad representation of your actual customers. Use all of this feedback to steer your app's direction.


Why not take your users on a steady gradual journey over time? Why kick them out of the airplane over unfamiliar territory? This isn’t the 1990’s, where massive releases were the norm. People no longer hire the Rolling Stones or U2 to launch updates. The world has changed. Abandon the Massive Release Mindset! You’re not mailing CD-ROMs or floppies to users; there are no material costs to save by piling up major changes into one massive release.

The more incremental your updates to your app, the lower the burden on existing customers, and the more specific your analytics and reviews will be. Stacking up big changes just stacks the risk: risk your customers will hate it, risk that the changes won't work correctly, and so on.

Skyscrapers of change looks beautiful while they upload it to the store. Apps always look sleek and clever before customers touch it. The moment of truth arrives soon enough. The update goes out, someone shouts JENGA!, and now you have pieces of app littering the floor.

Or maybe you got everything perfect. What do you think? Can you reliably ship a massive update without bruising your business?

No comments: