Categories
Uncategorized

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

Categories
Business Support User Happiness Web Apps

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.

Categories
Silliness

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.

Categories
Business User Happiness Web Apps

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.

Categories
Business iOS

How To Make An iPhone App That Actually Sells

So you’re a developer who wants to make an iPhone app, but you’re afraid that you’ll spend a bunch of time (and potentially money) building something that no one will actually use. You imagine releasing an app that people will buy on Day 1 as well as Day 361, but you have no idea how to make that happen. Well, today’s your lucky day! With a bit of research and consideration before you begin, you can dramatically increase your chances of making an iOS app that sells like crazy. I’ve had a hand in quite a few successful and not-so-successful iOS apps, and this is some of what I’ve learned.

Throw away your sexy idea
So you’ve thought up this amazing app that does something unique and you just know that once enough people “get” it, it’ll sell like crazy, or that the market is big enough for you to to make money selling anything that you can think up. That’s a huge red flag. While you’re busy thinking of clever apps, such as ones that take the music that you were listening to on your computer and start playing it on your phone, right where you left off, other developers are sitting at the top of the charts selling tons of copies of apps that let people take photos. So, obviously you need to…

Know your marketplace
The App Store is a treasure trove of information that can help you easily decide what to build, because it tells you what people are already buying. Given that at least 400 million iOS devices have been sold, even capturing a fraction of the market of apps that people are actually buying will bring in some good revenue. Look at the top sellers, and build things that fall into those categories. Right now, what I’m seeing a lot of is the following:

  • Apps that are a good upgrade to apps that ship with iOS (better calculators, calendars, email clients, cameras, to-do lists, etc), because many people will hit the limits of what the stock apps do and they look for something that does more. Generally, Apple builds apps with a lot of breadth (almost anyone can use them), but not much depth (if people want more than basic features, they need to look elsewhere, and that’s where you come in!).
  • Games (everyone plays them, and there are many types. Multiplayer games in particular are some of the best to build because there’s a built-in reason for people to share your app with others.)
  • Apps that do one thing that most designer/developer types would hardly ever think to build, because they seem SO simple… like Over, which is making bank right now, but it only does one simple thing: it lets people put pretty text on their photos. Something like Over might be a simple thing to you because you know how to use Photoshop, but it’s like black magic to many other people. Bringing a single useful feature that you take for granted to the masses can be a surprisingly good way to make a successful app.

Release early, release often
Many of the best iPhone apps are the ones that do one thing well. They let you get in, quickly perform a task, and get on with your life. With that mind, make an app that is polished, but only does one thing. Don’t throw a bunch of features into an app that you haven’t gotten into the market yet. When it launches and starts selling well, you’ll have a lot more confidence in spending the time/money to add features, and you can see how people are using it and factor that into your decision making.

It’s good to add features over time for another reason: When you release a new version, your app appears in your customer’s app updates list, which keeps your app top-of-mind.

Have a great icon
It’s possible to skimp on design for your icon and be successful, but you greatly increase your chances of success if your app has a great icon. For an iOS app, your icon is a huge part of your brand, because there’s a huge version of it on your App Store pages, it’s one of the first things that a potential customer sees, and it’s the thing that they tap on their home screen to start your app. Make the rest of your app great as well, but don’t skimp on your icon. There are tons of great icon designers on Dribbble, and that’s a great place to start. You can get great icons made for as low as $300.

So after reading all of that, I bet you’re a lot more confident about making an iOS app that will sell, sell, sell, and you’re ready to go and make the next blockbuster!

Categories
Business Launches

Launch: Stunning – Dunning, Receipts and more for Stripe

iTunesArtworkSorry I’ve fallen off slightly in my posting here lately.  I’ve been busy launching a new product:  Stunning. It’s an app that picks up where Stripe leaves off and adds some useful features that any developer who uses Stripe may find useful.  As an early adopter of Stripe, I had to write a lot of code when I first started integrating my apps, and I thought it’d be useful to bring the features that I wrote to all Stripe developers.

There are always a bunch of pitfalls when launching an app, and I ran into a bunch yesterday. For instance, when you are running a beta, you need to not only build forms to let new users sign up for accounts, you have to build forms for beta users to upgrade their current accounts, and there are things that you can’t really test for until you get things on your real server, so I spent a few hours hunting last minute bugs and squashing them.

On a related note, I found out last night that Linode support is AWESOME. I realized around 3AM that I needed another IP address for the Stunning server, and I had to open a ticket to get extra IP addresses enabled in my account. Linode support  wrote back and forth just about as quickly as I could reply. Super awesome, because it meant that I could launch Stunning as I planned instead of waiting for someone to get back to me.

So, back to Stunning:

Its main features are:

Dunning – It sends emails out when a customer’s credit card is about to expire with links to update their billing info, so that you don’t lose revenue and they don’t lose access to your service.

Receipts – Stripe doesn’t do receipts, but people always want to get receipts when they are charged. Stunning makes it super simple to set that  up.

Push Notifications  – on iOS, you can get push notifications for important events in your Stripe account, like when you get paid, when someone changes their plan, when someone new signs up, and more.

It can also send emails out when you refund a customer, when an account is cancelled due to non-payment, when a trial is about to expire, and for confirmation, and when someone changes their plan.

I think it’s a pretty awesome toolkit and I hope it proves useful to developers of all sorts. I’ve already gotten a few emails that seem to indicate that it’s super useful for some!

I also set up a domain to help people who are specifically looking for help with receipts for Stripe and searching Google for it. Receipts for Stripe.

Categories
Business Failures

Let’s talk about how I’ve failed: Part 1: Hngry v1

Lots of entrepreneurially minded blogs talk about their successes and how they happened. Not many people want to talk about failure, or even just those projects that  don’t grow but still refuse to die. Every successful business person I know has had at least one failed product, and usually a small string of failures that lead to success. The trick is to learn from your failures, figure out why they failed, and to try to do better at the things that you did badly the last time. Always be learning. I’ve seen a lot of people write lately that if you aren’t shipping, you’re dead. I don’t really believe that, but I do believe that if you aren’t learning, you definitely are. Things will pass you by so quickly and you’ll have a terrible chance of succeeding if you aren’t constantly learning and trying to do better.

So on to the first web app I ever made: Hngry. Hngry was the first app I ever wrote in Ruby on Rails (I literally wrote it as I read the first version of Agile Web Development With Rails), and I was super proud of what I’ve made. I got Louie Mantia (total rockstar these days, but back then he was just a young designer with a lot of talent) to design some icons for me, and I launched it. I built it because at the time I was in college, and my girlfriend and I ate out a lot and always had the same conversation: Where are we going to eat tonight? And, what are we going to eat there?

hngry

It was a web app that used the Yahoo Local API to let you search for restaurants in your area and add them to your list. You could browse metropolitan areas and see popular restaurants in that area. Each restaurant had a rating and users could review it, see maps of the restaurant’s location (using the Google Maps API), and eventually even add menu items/photos. hngryover

I’m pretty sure there was a tag cloud or two in there as well, because it was right in the middle of the big Web 2.0 movement. There were Hngry widgets for PC and Mac. I was super excited about it, and I thought it was great. A few people told me they liked it and that it was useful to them. Then I saw this blog post: http://www.disambiguity.com/hngry-not-that-hungry/ which ruined my week, and which I still can’t get out of my mind to this day.  She basically panned the whole app, calling it things like “fundamentally flawed”, “obviously hasn’t had the advantage of any kind of designer, interface, graphic or otherwise”, (little did she know that I’d actually paid someone to do the icons, although I must say I wasn’t and still am not the best at web design), and even called it a “wasted effort”. At the time, it was actually moderately successful (it had a few thousand users), which made her comments even more confusing to me.

 

I took it super personally. I spent all of this time building the app, working hard on something I thought was awesome and useful (because I’d heard/read over and over again that you were supposed to build things for yourself first, because lots of other people have the same problems as you), and who was this person to just trash my first real web project? Who did she think she was? Why did she pick such a rude way to go about saying what she said?

Eventually I (mostly) got over it, and I added some of the things that she was talking about, although she never came back to the product, as far as I know.

Most of her issues with Hngry stemmed from the fact that in building the app for myself, I’d forgotten about the other users and their problems, and why they’d even want to use Hngry at all instead of whatever they were already doing. Sometimes your biggest competitor isn’t another app, it’s people who are comfortable using “broken” solutions to their problems. Speaking of that, at one point, I decided that the way that Hngry would make money would be by charging restaurants to be able to customize their pages, add additional information, like specials and coupons, and have a nice home for their restaurants on the internet. This was 2006, and lots of restaurants didn’t even have web presences at all, so I figured that it’d be an easy sell. I even joined our state’s restaurant association in the hopes that I could talk to restaurant owners personally, get them on board, and work from there. Well, the first part worked. I met and talked to a lot of restaurant owners, and they were nice enough. However, they didn’t really see a need for Hngry (even though they thought it was a neat idea), and not one restaurant owner ever paid me for a custom Hngry page, which was really sad because I had printed up thousands of cards that they could use to promote their custom Hngry pages.

PreviewPreview

I couldn’t even bear to throw out the boxes of cards until we moved for the second time 2 years ago and I decided I had to let it go. Lessons learned: Don’t print up promotional material for something you haven’t even sold yet, and don’t pay much attention to people who just tell you something is cool. Get a product out there and see if they buy it. That’ll tell you all you need to know.

Hngry wasn’t a total failure, though. One day I decided to add menus to the site, and I googled for companies that were making menus available online. The one that stuck out was Campusfood.com, which eventually ended up becoming DotMenu, which was bought recently by GrubHub. After talking to me for awhile over email/phone, those guys decided to fly me out to New York to talk to me about working together and pick my brain, and after I gave a presentation to their CEO, President and a few other people over there, we worked together for a few years and integrated over 200,000 menus into Hngry, with online ordering through them. I even got a job offer (which I ended up turning down, mostly because their web stack was ASP, and I already knew that no matter how much I liked the people or projects, I would not want to write ASP as my full time job). We still worked together for years after that, though eventually I ended up shutting the first version of Hngry down after Urbanspoon showed up and did a lot of what Hngry did, but better. Pretty awesome outcome for a “failed” first project, though.

So what else did I learn? I learned how to write web apps in Rails. I learned how to connect to APIs. I learned how to set up a web server. I learned how to talk to CEOs. I learned that building something that you think is awesome does not necessarily mean that it will be successful. If you build it, they might not come. I learned that even though some people might be harsh in their opinion of your app, you have to listen to their actual points and decide if they are valid, and try to ignore the meanness. Also, it taught me to listen to people who actually use my apps.

I used some of these lessons down the road when I relaunched Hngry as an iPhone app. More on that later.

Categories
Uncategorized

Save yourself from redundant support requests.

Over the years of running busy web apps, I’ve answered a lot of support requests. Over time, I’ve noticed patterns of the same kinds of questions being asked by different people. Generally, what people think of when they think of the process for support requests is pretty straightforward: Get notified that something isn’t working properly, fix it, let the person know it’s fixed, or answer questions about how your app works. But I think you can take it a little further ,and improve your app in the process.

When people keep asking me the same questions about how my app works, or why it does something a certain way, or I get repeated support requests which are due to the customer not configuring things properly, I see it as an opportunity to make the app better. When I notice that something has been asked more than a few times, I start to ask myself how I can make changes to the app so that I never have to answer the question again.

This process is different for every app, but here’s an example of my own: On Are My Sites Up, I’ve noticed that people tend to not look at the settings too closely and end up leaving their Timeouts setting off. The Timeouts setting is a switch that sends you a notification when your site is responding slowly if it’s switched on, and ignores slow sites if it’s turned off. We used to have it turned on by default, but we found that there are a lot of customers out there who don’t actually want to know when their site is slow, because their sites are slow on a regular basis. Now it’s off by default. This change has made me end up having to answer email that I get from customers who wonder why their site went down without any notifications being sent to them. It’s because of a failure on my part to make sure that customers know what the Timeout setting is for and how to use it, so I’m working to fix that.

Right now I’m working on an update to the signup process, where the first time you log in, AMSU explains how Timeouts work and why you’d want to have it on or off, and I’ll let the customer decide up-front what setting they want. That way, they’ll know what to expect, and I’m sure I’ll be answering a lot less questions about that in the future. So, I guess what I’m saying is: Use support requests as an opportunity to improve your app, whether it’s fixing bugs (which is the more common situation) or fixing the user experience of your app (which will pay dividends for years down the road with customer satisfaction and a decreased support load.)

Categories
Designers

Getting An Icon Made For Your iPhone App

I’m no designer, so I’ve had to hire designers to make icons for my iPhone apps a few times. I actually just got one made for Stunning. Here’s what I normally do:

  1. Search Dribbble for designers who have done good work, in the style that I want. Sometimes I can even find a designer who has done something really close to what I want. I generally get a really good deal then, because they already know how to do what I want, and they’re just modifying a process that they already know. Dribbble even shows you who is available for work, and you can message designers right from within Dribbble. Price-wise, over the years I’ve paid between $3000 and $300 for design work, depending on complexity.
  2. Write a descriptive email/Dribbble message that describes what I want in as much detail as possible, and ask for a quote.
  3. Make sure that I get quotes from multiple designers, so that I can compare the market and play the quotes against each other when negotiating.
  4. Once I’ve collected a few quotes, sometimes I ask the person with the highest price (if they’re my #1 choice) to bring their price down by some amount, mentioning other, lower quotes that I’ve gotten (for leverage). Note that they might not go for it, so you have to be prepared to walk away completely and get another designer to work on the icon.
  5. Pick a designer, and pay them some up-front money to get them started. In most cases, I’ve paid 40% or 50% up front, and the rest on completion. I’ve never had a problem with getting revisions made to my icons, but I keep the number of revisions within reason. It’s very good to start with a well-defined idea so you need less revisions later. Designers are usually happy to do them, though, because they want you to have a good product in the end. Oh, and one more thing, when describing the revisions that you want, you might want to use something like LittleSnapper or Skitch to annotate and draw arrows on your image, to accurately point out where you want things moved to/from.

Then, the designer will normally tell you how long it’ll take for them to show you something, and they’ll send you some sketches so you can agree on a direction if need be, or they’ll just get started on the icon and show you something more final if everything is more well-defined.

If you do this a few times, you’ll end up with designers that you trust, and who you work well with. It’s a good idea to start with those guys first and see what they can do for you. They’ll appreciate it, and you’ll have more of an idea what to expect because you’ve been through the process with them before.

Hope this helps! It’s not a difficult process (if you know what you want your icon to be). Deciding on the icon is always the most difficult part for me.

Categories
User Happiness

Keep your users in the loop when doing support.

I’ve found that users really appreciate hearing back from me as soon as possible, even if it’s just to say that resolving their problem will take longer than expected, or that I’m working on it. In the world of web apps, where you can send an email and get a slow response, or even none at all, users find it really refreshing to get a quick response just so they know someone is on the other side, even if the issue isn’t fixed right away.