Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.
Background On Documentation
Over the last couple of days, we’ve written about how to structure documentation to define what users can do with the software, instead of capturing what the software can do for users. This reverse approach uses user goals to guide our documentation. We also presented, more concretely, how to trace and manage our goal-driven documentation with use cases.
We can leverage this documentation approach to achieve two additional benefits:
- Encourage users to install new upgrades
- Encourage users to migrate from other applications to ours
The same factor is at play in both situations – users already know how to use their existing software, either a previous version of our software or a competitors software. The fundamental question for users is “How will I do what I need to do?” This is a major barrier to both upgrades and migration from other applications.
Kathy On Upgrades
Kathy’s article on why users don’t upgrade is awesome. She creates a great visual graph (shared via her CC license) of the user’s perspective on upgrades:
Kathy goes on to list several approaches to address the problem, all of them fall into either “make them want it” or “make it easier.” We will focus specifically on how writing goal-driven documentation can help.
Make Them Want It
We must apply the same prioritization approach to defining upgrades as we do to defining the initial release. This assures that the most valuable not-yet-implemented goals are addressed in the new version of the software. If we are using Kano as a framework for prioritization, we have the added benefit of effectively lowering the suck-threshold.
Make It Easier
We can make design decisions that make software easier to use. We can also follow Kathy’s other good suggestions. And we can write our documentation to make it easier for users to make the change.
Goal-driven documentation has two effects on the curve Kathy drew above. Here’s the same curve, representing a typical software upgrade:
With goal-driven documentation, the curve is shifted up and to the left:
This shift can be analyzed as two different factors:
The goal-driven documentation allows users to climb become more competent more quickly – effectively lowering the suck-threshold. When applied to upgrades, it reduces the size of the drop – preventing users from re-entering the suck-zone.
Faster Climb
Competence is not a measure of how quickly users can do everything the software can do – it is a measure of how quickly users can do everything they need to do with the software. When we define our software to prioritize solving the most valuable problems for our customers, we are defining the set of activities that the users need to do. And we identify this as a set of use cases.
We then document how users will follow those use cases, with the implementation we’ve given them.
This goal-driven approach to documentation helps users climb the competence curve much faster, immediately reaching the “Finally I can actually DO something” point (above the suck threshold). As long as we document the right somethings, we’re all set.
Shorter Drop
We apply this same approach to our upgrades. Those use cases that we’ve added in a new release yield new documentation. Those implementation areas we’ve modified as part of the upgrade yield updates to previously released docs.
Users will have an easy answer for “how do I do it now?” as well as “What can I do now?”
Collateral Benefit
We also get the benefit of making it much easier for users to migrate from other software packages (not just our earlier releases). There are books out there where authors address exactly this problem – Microsoft Word for Wordperfect Users and Java For Cobol Programmers come to mind. By showing users how to do what they need to do, we make it easy for them to switch.
Conclusion
- Goal driven documentation makes it easier for users to learn how to use our software.
- Goal driven documentation makes it easier for users to switch from other software programs to ours.
- Goal driven documentation makes it easier for users to upgrade to new versions of our software.
