Spurred on by the DevOps movement, "continuous delivery"--a form of software delivery that emphasizes constant updates to applications--has become the order of the day. Continuous delivery has many benefits, but it also presents a major challenge: If improperly managed, continuous delivery can confuse end users and undercut the advantages that continuous delivery is supposed to confer.
Keep reading for tips on ensuring that continuous delivery actually delivers on its intended goals, instead of causing continuous confusion.
What Is Continuous Delivery?
Continuous delivery is an approach to software deployment and updates that has been popularized by the DevOps movement. Under the continuous delivery model, new application features or other changes are developed, tested and deployed to production environments on a regular basis.
There is some debate about whether continuous delivery should be considered a step up from agile development or just an evolved form of agile. However you want to think about it, what’s important about continuous delivery is that it’s the exact opposite of the old "waterfall" approach to development. Under the waterfall model, IT teams waited until a major set of new features had been completed, developed and tested before deploying a new version of their application. As a result, users would typically go months or years before seeing any significant application updates, with the exception of major security fixes.
The fruits of continuous delivery are all around us today. If you log into your Web-based email client and notice that the interface has been changed a bit, even though there has been no major overhaul of the application, that's probably the result of continuous delivery. Similarly, continuous delivery could allow a mobile app to become compatible with a new type of hardware device without any significant version change to the app.
Continuous delivery benefits end users by providing them with faster updates. It also helps developers and system admins by making it possible to provide security, performance or feature updates quickly.
How Continuous Delivery Can Frustrate Users
Being able to update applications quickly and constantly is useful for a variety of reasons, but the model has one major drawback: Rapid application changes that users don't usually expect can lead to confusion.
Imagine, for example, trying to set up an event invitation using an online calendaring app whose interface was subtly changed without any warning to you, the end user. Maybe the button for submitting changes was moved. Sure, you could probably find the new location of the button easily enough, but having to do so will disrupt your workflow and cause some amount of frustration.
The negative effects of continuous delivery on end users could be more significant. For instance, maybe an application that once required only a username and password to log in has added multi-factor authentication and now requires users to enter a passcode sent to their mobile devices. That update will enhance security, but if your users don't have any advance warning, they might not have a mobile device available when try to access the application. As a result, they won't be able to use your app--which is bad for your users and bad for you.
Continuous Delivery Best Practices
How can IT teams avoid the potential of continuous delivery to confuse and frustrate users? Here are some tips.
1. Alert users.
An important and obvious step is to make sure that users are aware of changes that impact them. Ideally, users should receive warning of a change in advance. Before you roll out a new feature that is likely to disrupt the way users work, let them know change is coming. If advance warning isn't possible, or if the scope of the change doesn't merit a notification in advance, you can still let users know once a change has occurred via a simple pop-up or introduction message.
Keep in mind that you'll want to keep notifications short, sweet and intuitive. Don't make users read through a block of text in order to understand what's different about their app.
Remember, too, that not every change requires a notification. Application updates that impact the back end and are not likely to be noticed by users probably don't require a warning. Neither do very small interface changes, like a change in color. Use common sense when deciding what to notify users about.
2. Revert to old versions.
Giving users the option to revert to an older version of your application is another useful way of minimizing the potential confusion of continuous delivery. In most cases, you won’t be able to give them this option indefinitely because that would mean maintaining multiple versions of the same application. But, in the case of significant updates, like an interface overhaul, you could maintain the old interface for, say, a couple of weeks or a month, and give users the option of reverting back to it during that period. Users will have to accept the changes sooner or later, but givingn them the option of reverting will allow them some flexibility to choose a convenient time for migrating.
3. Test changes on a beta group first.
You might also consider establishing beta groups of users who receive continuously delivered updates before other users. Your beta users could be people who have opted in to early (and potentially unpopular) changes. Or they could be users whom you have reason to believe will be less impacted by changes, based on factors like how long they have been using the application or which types of devices they use. You can then release changes to beta groups first and solicit feedback from them before rolling out changes to all users. This strategy can help you to smooth over issues with continuous updates before they reach your general users.
4. Think hard about changes before you make them.
The strategies listed here can help users adjust to continuous updates. A final point to keep in mind, however, is that continuous delivery will be less painful for your users when you avoid making unnecessary updates in the first place. The continuous delivery model can make it attractive to implement a change quickly, without properly designing or testing it. Resist this temptation--just because you can change something quickly in your app doesn’t mean you should. Design user interface changes carefully, and think hard about how a change will impact overall user experience before you decide to implement a change.