There’s an inherent tension in product development between improvement and stability. On the one hand, users expect new features, functionality and maybe even a new look; on the other hand, changes can backfire when familiar interfaces suddenly disappear. This tension is greatest when a product is changed in a dramatic way – so much that it could even be called a new product.
At CaseFleet we learned some of these lessons the hard way, albeit at a very early stage in our development. Initially, our application’s navigation was located in a row of icons along the top of the page:
Despite the aesthetic value of this choice, we felt somewhat constrained by the amount of space available, particularly when our users were viewing the app on smaller screens or mobile devices. One day, one of our developers arrived to work on a Monday morning with the fruits of an unannounced weekend project: a proof of concept of change to the layout. The core of the change moving the navigation from a row along the top of the screen to a column along the left:
Our team thought the design looked fantastic and, after adding a few finishing touches, we released it to our users that week expecting that they would be thrilled. We were wrong.
While a handful of users immediately embraced the change, a substantial number were not happy at all and reported having difficulty moving around the application. Their biggest complaint, however, wasn’t that they didn’t like the new layout but that it caught them off guard.
Lessons Learned: Change Done Right
The next time we changed our application, we used a far different process. Our key insight was that users like to be in control of their destiny. When they pay for your application, they do so for a reason, and they don’t want their treasured features to be taken away from them.
After we completed our newly-designed interface, we did not simply release it. Instead, we wrote a blog post about it and shared screenshots with our users.
Next, we added a button to the welcome screen in our app with a large headline, some carefully-crafted copy and a big orange button welcoming users to try out the new version. We also noted that they could revert to the original version if they wished (for a while anyway).
Once users were in the new version, the steps required to revert back were located several clicks away in the user’s profile settings. We didn’t want to hide the button to revert, but we also didn’t think it would be useful for people to toggle back and forth repeatedly, which might have been tempting if the button was immediately visible. In fact, only one user ever reverted during the month-long opt-in period. Moreover, by the time we flipped the switch and made the new version mandatory nearly all of our most active users had switched over and given us great feedback on the new version.
In addition to the in-app incentives we provided for switching over, we sent several emails letting users know exactly when the change to the new version would be made permanent. No one was caught off guard and no one complained. In fact, most users were extremely pleased with the new look.
Still, it’s important to note that releasing an update in this way is not free. Your development team will have to maintain two separate versions of the same codebase and you’ll also have to solve complex problems around how the versions are sent to end users. Your development and quality assurance teams will be exhausted by the end of the process, but you will probably agree that the investment of time and resources was a smart one. In hyper-competitive software markets, you must keep users happy and there’s no quicker way to make them unhappy than to suddenly change your interface.