Introducing new features in your released software

Imagine this: you have released your software. As with any software releases, you had cut corners, last minute compromises had to be made, features had to go out without all the bell and whistles, etc. Yet, you users loved the software, and they have started to use it. As you start getting new users, you are also starting to get requests for features you had compromised on during the release. And people are complaining a bit about the UX, there were things you had thought made sense but it’s not so obvious for your users. You now realize that you have to update your software with a new version.

The good news is that it’s a web app, so updating is just releasing a new version overnight, making sure people’s data isn’t lost and you are done. But the bad news is that your UX fixes and new features mean you’ll need to revamp how the software will be used and the interface is likely to be completely redone. It’s bad news because you know that some people will get confused with your new UI because they’ve learnt your current interface and are using it.

What do you do?

Here are some strategies that we’ve been advising our clients with and they come from working on hundreds of app releases and update.

Release often, but only at the start

“Be agile; release early; release often.” that’s the the drill. But it is strategically wise to keep rolling out features only at the beginning of a product roll out when you don’t have that many users. When your product reaches a certain size, a certain number of users, you don’t want to risk the integrity of your application with every new minor release. The worst thing that can happen to your product is that loyal users, customers who have been using that one little feature consistently over the years, suddenly aren’t able to use it in the same convenient way. The change might empower users more, but the experience becomes less straightforward. Frustration and anxiety enter social media quickly and suddenly, and the pressure on customer support to respond meaningfully and in time increases with every minute. Of course, we don’t want to roll out new features only to realize that they actually hurt loyal users.

So the plan should be:

Release early, release often only at the beginning of product’s life

Announce the release

You should have a list of its current users. Use that list to communicate that changes are coming so people are prepared. Plan on sending an email announcement, explaining your new upcoming plans, with dates and list of feature changes.

Create a video showing what’s going to be new and more importantly how it will improve things for your users. Remember, this not just a boring news of updated software but it’s an advertising to get your users excited about the new features. That excitement will help ease the pain of learning and adapting to the new interface or the new way of doing things. A lot of people are visual learners and this preview will make the changes feel less unknown the next time they use your software. Sometimes even a animated gif does the job well. Here’s google introducing a new feature with a very short animated gif.

Or basecamp doing a in app popup letting people know about changes that are about to happen. Trello does something similar with their “New stuff!!” fox at the top.

Have app Tours & Walkthroughs for new features

When your users use your app all day long a new update can greatly affect your efficiency. You can easily address that negative by providing a short and easy in app tour to re-teach user behavior and help users with missing or moved features. There are different types of tours, but the ones that point out and walk users through how to use a new feature and answer any common questions works the best in our experience. Gmail has a great one that you must’ve seen. Here’s one I saw recently that I liked.

The good news is that it’s easy to add these in app tours. There are several great products out there that makes it pretty easy. Try out Stonly or Intercom for a start.

Have a “I’ll try later” option

This may not be the easiest option from a dev point of view, but it would be wonderful if you can do it somehow - the option that let’s users use the old interface for a while. Very useful when your users have something urgent to work on and you come in with your all new shiny interface where nothing is where it was! Facebook has them all the time when they do their big UI shifts, but they are Facebook. But you don’t always need thousands of developers in your team to do this. Nifty tricks like having the older version still available on a server and click to redirect users to that version might suffice in some cases :)

Ask for feedback

Sometimes all it needs for your users to be OK with your changes is a simple “sorry for the changes, we welcome your feedback” message somewhere. This humanizes the software and let’s your users know that you are putting them in trouble and that you are willing to listen to them.

Remember how angry we would get every time MS would drastically change their interfaces? We learnt the new way of doing things but we were looking for some way to tell MS what then shouldn’t have done!

Anyway, software is always going to be updated, so you’ll just need a way to make those updates less obtrusive to your users. This is a fact of life! Happy software development…