Monthly Archives: February 2013

Get more trial users to convert by making these simple improvements to your web app.

So you’ve just released a new web app, but people are signing up and then not using the product, or signing up and then deleting their account shortly after. You can’t figure out why this is. You know that you’ve built something that’s useful to your target market, so why aren’t people sticking around? We hear a lot these days about the importance of A/B testing, using content marketing to get more users to our sites/apps, optimizing conversion rates, improving our funnels, and more. That’s all great, and it really starts to pay off later on, but what if you could improve your chances of converting a user who has already signed up for a trial of your service by making simple improvements? You can.

For a long time, I incorrectly assumed that customers who were having trouble or who hit an error with a product that I’ve created would contact me via one of the support channels that I have set up (live chat, Intercom, etc) if they ever needed help. Links to support are readily available on just about any page of my web apps, and I try to respond pretty quickly to all support requests.

Over time, as I’ve monitored my web apps with exception tracking software, I’ve realized that after hitting just one error or glitch during their trial, some users will completely abandon my apps and leave, never to be seen again. They’d much rather take the path of least resistance and just abandon the app altogether than spend a minute typing their support request into a box. I’ve seen this play out multiple times: Someone hits an error or has an issue, and 2 minutes later, they delete their account.

Here’s how you can fix this:

  • Install some error tracking software. I recommend (and use) Sentry, but there are several alternatives to be found. Generally, this requires installing a tiny bit of code into your app (if you’re using Ruby on Rails, you just add their gem to your Gemfile and then bundle), and adding your app’s key into your app.
  • As soon as you get an email notification that a user has an issue, fix the issue ASAP (I’ve found that issues which users hit during their trial are usually relatively simple errors).
  • Then, be proactive and reach out to them that same day, ideally within an hour of their error.
  • I generally say something like this (I’ve made it generic so that you can modify and use it if you’d like):

    Subject: [APP NAME] Error that you experienced this morning

    FIRST NAME-

    From our logs, it looks like you hit an error this morning when you were trying to do THING THAT THEY WERE TRYING TO DO. I’m very sorry about this, and I just wanted to let you know that the issue has been fixed. I know that it’s frustrating to have problems getting started with a new app. I’d like to invite you to give it another shot, if you’d like.

    LINK TO APP

    Thanks!
    YOUR NAME
    Founder
    APP NAME

    I’ve never seen this fail. I’ve gotten exactly 0 replies to this email but a 100% success rate in people signing up again and giving the app another shot. You’ve gotten a user all the way through coming to your site, reading about your app, signing up, and even being convinced to give you their credit card in some cases! That’s the very definition of a qualified lead. Don’t leave these users out in the cold.


  • Bonus points: Don’t forget to style your error pages to match your app, put easy ways for a user to contact you right on your error pages, and give them an easy way back into the app. Don’t leave generic framework error pages up. They usually just leave a user stranded and out of your interface, with only the Back (or Close Window) button as their escape.

Here’s a visual comparison of the difference. Ask yourself, as a user, which would you rather see if the app that you’re using encounters an error?

This?
Screen Shot 2013-02-16 at 6.09.19 PM
Or this?
Screen Shot 2013-02-16 at 6.05.48 PM

Always keep your customers in the support loop

We all know that when someone submits a support request,we should get back to them as soon as possible, but what about the support requests that take more than a few minutes to resolve? If a problem isn’t resolved on the day that a ticket is received, let customers know where you are with the issue, that you’re working on it, and how much longer they can expect for it to take. They’ll appreciate and respect you for it. As a customer, it’s terrible to take the time to write in about a problem and not know if you’re going to get a response in a timely fashion, or at all. Put yourself in the customer’s shoes and you’ll know what to do.

Silly App Idea of the Day – Yet another to-do list app.

I’m doing this in jest, but if you do build some app that I’ve come up with as a Silly App Idea, please link back to the associated post :)

Here’s a silly app idea that I had today:

I want to make a to do list app where the font/checkbox gets larger and larger the longer you wait to check something off, so you feel more awesome when you check off that item after 3 months of staring at it.

Never stop improving your design.

When Are My Sites Up launched in 2009, we didn’t have many options on the Settings page. Over time, as we added more and more features, we started to outgrow the original layout, which was a few fields that just contained email address and a few checkboxes to turn some options on and off, and a field for the user’s SMS number. Since 2009, we added

  • The ability to change credit card info
  • iOS Push Notifications
  • Android Push Notifications
  • Voice Calls
  • International SMS
  • The ability to buy SMS and voice call credits
  • RSS Feeds
  • User Management
  • Contact information for invoices

Each time we added something else to the page, I noticed that it was getting longer and longer, and that eventually the straw would break the camel’s back, but there was always something more important, or more pressing. Today a user asked to get a copy of their past invoice, and I decided to add that to the site so that users can generate their own invoices at will. As I scrolled all the way down the page looking for the best place to add the invoice links, I realized that today was the day that it all had to change. It’s pretty embarrassing that it got to this point.
settings-old

Today I took the extra 30 minutes to implement a jQuery accordion, and now the page looks much better.

settings-new

It actually contains more information than it did before (now there’s a list of links to all past invoices in there), but it is much easier to digest, scan and actually use. I’ve already heard from a few users who love the change. I just wish I’d made it sooner.

The moral of the story is: Always make your product better on both the technical and UX sides. Keep tabs on design choices that your feature set has outgrown, and assess your UX periodically to see whether or not things need tweaking. It’s a difficult balance, but your users will love you for it, and be more loyal because it shows that you have a dedication to improving the product over time. The same thing applies to iOS apps: if you continually make small fixes and updates, your users will notice and appreciate them. I’m working on getting better at both.