I was discussing recently the importance of getting a product installation or upgrade process right for customers. Here are some guiding principles from a usability perspective that you may wish to consider when defining your product’s requirements.
1. First impressions #
We must always remember that a customer’s first experience with a product is its installer or upgrade process. Customers expect it to “just work”, but if the install / upgrade goes wrong for any reason, this will tarnish their view of and their confidence in the product itself.
2. Changes #
Tell them what’s changed in this version of the software and why because experienced users hate having to re-learn stuff they were already good at. Tell them before you start and remind them when you finish.
3. Simplicity #
It is our responsibility, not the customer’s, to have to deal with the complexity of our products, their install processes or configuration
We cannot assume that customers are on the most recent version of software prior to upgrade and must simplify the process of getting the customers from old version X to new version Y.
Customers probably don’t know, nor care which version of a product they’re on. They’re interested in what their current product does for them now, and what it potentially could do for them in the future if they upgraded.
Minimise (ideally to zero) the amount of information an ordinary user needs to supply during the upgrade process, but give power users the option to evaluate, override and customise otherwise automatic choices
4. Dependencies #
It is our responsibility, not the customer’s, to check for pre-requisites we dictate, e.g. disk space, working network / internet connection, third-party software dependencies, licence keys, 32-bit/64-bit, operating system version etc.
5. Don’t break a working system #
Customer must always end up with a working system, regardless of whether automated upgrade succeeds or fails.
A working system = config settings, licence keys, customer data, product state as customer had prior to the upgrade
A customer will generally not know and remember all their configuration settings, and the person doing the upgrade may not necessarily have been the person who originally installed and configured the software
If the upgrade fails, we must automatically recover the system to the original working state as if the upgrade had never happened
6. Context and progress #
Customer must always know what is happening during an upgrade
Overview of what will happen and how long it will take before starting the process
Visual progress reporting during process
Meaningful and concise descriptions during process of what has happened (success / fail), what is happening now, what needs to happen next
Confirmation on completion of process
7. APIs #
For integration customers, if the version (or contract) of an API changes as part of an upgrade, the older version of the API must remain available alongside the new to allow their software upgrade to proceed independently of the customer’s decision to upgrade their integration.