The three (design) mistakes of my life

[Note: an abridged version of this appeared on YourStory last week.]

Don’t you get irritated when you make a rookie mistake?

width=1000

I’ve been reading a few books and articles on product design lately (I recommended one of these in last week’s newsletter). Some recent, and some classics that designers still swear by, 30 years after first print. Comparing the two, one thing struck me. Devices, user interfaces and users have morphed beyond recognition. But the principles of good design haven’t.

Yet, we still make tons of elementary mistakes. I know I do. These were silly mistakes then, and they’re silly now. It’s a cycle we’re all prey to – make a few basic errors, learn from them (I’m optimistic), and then go make some new ones.

But, surely, reinventing the wheel is not efficient. Each time someone repeats a basic mistake, it’s a waste. A waste of our collective efforts.

So here’s my attempt at reclaiming squandered time. Here are the three most critical design mistakes I’ve made. I hope others who are building new products can learn from them (or scoff at me – I know I run that risk).

 

A. Not Onboarding the User (or Onboarding her, but badly)

Design gurus talk ad infinitum about the importance of onboarding users. And it’s also common sense. Therefore, in the first version of my app, I included a six-screen tour upfront to help users immediately see how they could get value from the app. But that didn’t work.

In a world where you lose 80% of your users within 3 days, users don’t just want to see the value upfront. They want to get the value immediately.

So, after a few cycles of lower user activation, we now focus exclusively on soft onboarding – guiding users as they do actual activities on the app, rather than “teaching” them before they enter.

[Tweet “Users don’t just want to see the value upfront. They want to get the value immediately”]

Another mistake we made was asking the user to invest too early.

If you ask the user to do some “work” before she’s sold on the app’s value, you’ve lost her. Let’s say you ask users to create an account. 90 per cent won’t if they’re not convinced that the app is great. What about Facebook login, you may ask. Yes, it takes only 14 seconds. But no, that’s too long.

To overcome this, we made the registration simpler in each successive iteration. First, we reduced the number of mandatory fields. Then, we removed some fields altogether. Then a couple more. Finally, we had only “mobile number” left. Just one ten-digit number, which your fingers know by rote; surely that’s not convenient? But still, user metrics were quite deflating.

It was only when we removed the login altogether that our sickly funnel began to recover. We now collect the mobile number only once the user completes her first iteration through the app – when she has already derived some value from it.

Moral of the story: Unlike your investors, your users need to see the return BEFORE they invest

[Tweet “Unlike your investors, your users need to see the return BEFORE they invest”]

 

B. Not Optimizing User Funnels

On the mobile screen, space is scarce. And given the vast multitude of competitors vying for your user’s attention, space in her mind is, if anything, in even shorter supply.

Blog00003

Therefore, you must keep things simple. Don’t make the user think about what she wants to do. Once she opens your app, the next step should be self-evident.

There are two ways to mess up here: (a) give the user too many options; or (b) put important actions deep inside the app. We paid attention to the first, but missed the second. No matter how many triggers we gave, if a functionality was two or more taps away in some menu, users wouldn’t see it.

Finally, we mapped out the possible user flows on the app. And redesigned it such that the user sees what she’s looking for on the first screen itself. And not in some corner of the header. Front and center. No brain cycles wasted makes for a happy user (and a happy me).

Moral of the story: Think about all the contexts in which the user will use your app, and make each of these as simple (one-click) and clear (visible) as possible.

[Tweet “Show your user exactly what to do – no brain cycles wasted makes for a happy user (and a happy you)”]

A related issue that several apps (including mine of course) suffer from is that funnels tend to be too long.

It’s pure wishful thinking: “I’ve placed a pot of gold at the end of the funnel. The user will jump through as many hoops as I place in the way.” Won’t happen.

We did this too. In one funnel, for example, we wanted the user to (a) watch a video; (b) answer a couple of questions; and (c) take a photo before they saw any value from the app. Some of our early adopters were enthusiastic enough to do this. But alas, this smoke did not bring fire, as our user base expanded.

Today, we’ve made our funnel much shorter, and are seeing far more users complete the journey through it. And they’re earning their (small) pot of gold.

The important learning for us here was that shorter funnels are always more optimized for conversion.

  1. Removing low-value actions from the user flow increases the prominence of the high-value steps
  2. Highly optimized flows make it insanely easy to understand, “what do I do next”
  3. The user gets to her “AHA!” moment much faster and more often. This is especially important – as Facebook and Twitter will testify, what users do in their first visit is often a strong predictor of eventual loyalty and retention.
  4. Fewer moving parts means it’s easier to tune the engine going forward as well.
[Tweet “The shorter your funnel, greater the likelihood that users will reach their AHA! moment.”]

 

C. Not personalizing user messaging

Blog00001

I learnt early on that notifications are quite powerful. When a user first installs your app, she may not check it often. Notifications help build the habit. Make her phone buzz every day with a message from the app, and she’ll check in often.

So, armed with time-tested copywriting wisdom, I set to work. I focused each message on the user benefit, and put a clear call-to-action each time. And it worked!

For a time, anyway.

Early on, we would get a solid bump in user engagement in the few hours after a notification. But that quickly fell away. As users got more acquainted with our app, the standard daily messages, albeit highlighting user value, became just noise. Of course the user knew how she could benefit from our app. She’d been using it for a month! After receiving a stock notification for five straight days, the only action users often took was to uninstall the app. As we very heartbreakingly heard from some of our (ex) users.

[Tweet “On receiving a stock call-to-action message for 5 days, the only action you take is to uninstall.”]

The only notifications that work sustainably are personalized messages. I don’t mean just including the user’s first name in the notification. That feels clever, true. But here’s the thing – every app worth its salt does it. And the user knows it’s automated.

Instead, customize the message based on what the user does on the app. If a user comes to your app every day for five days and suddenly misses a day, then tell her you’re missing her (in a non-creepy way, of course). If she’s close to a milestone, remind her of the rewards awaiting her. Remind of her recent wins on your app to bring her back. Even if a user knows these notifications are machine generated, they still work.

Referencing users’ past activities creates a much stronger hook, reeling them in.

Today, we strive to send more personalized messages to users, uniquely tailored to their usage of the app.

 

D. Bonus mistake – not learning from any of the above

Since you’ve stuck with me this far, here’s a bonus mistake. This is as rookie a mistake as they come.

Over our initial few months, we made several design changes to the app in each version. So, when user behavior changed (or didn’t change), we weren’t really sure what the driving factors were. Which changes helped, and which ones didn’t? Were none of them helpful? Or were some cancelling out others? No clue.

And even in those situations when the data may have had definite implications, we weren’t disciplined about looking at the numbers and learning. Does a tree fall in a forest if no one’s around, etc.

Now, we try and make changes in such a way that we can track their impact. Make a change, wait a while, and check for variance in user behavior. That’s the only way to learn what’s working and what’s not.


I hope I’ve learnt from these mistakes, and that our bucket won’t be as leaky now. What about you? What are the design mistakes you’ve made, that now make you cringe? Drop me a line at [email protected] or @jithamithra, or just comment here. I’d love to hear from you.