The Final Step

 

You hired the best programmers, used the latest tools and talked to the users to really understand their needs. Testing found both technical and usability bugs. You are confident that this will be the most stable, feature rich product you have ever shipped. Now you need to write the release notes and you are done. You ask the programmers what they did, write a couple sentences about each feature turn it into a PDF and you are done!

 

Not so fast. The release notes are critical for your customer’s success. Features they don’t know about will not be used. Features that are poorly understood will be misused. The release notes cannot be an afterthought in the design process.

 

The most important criteria when designing commercial software is understanding how people actually use the product. The same applies to release notes. Customers have their own businesses to run. Not every employee has the same job. Therefore not every feature has the same importance to every employee. Wouldn’t it be nice if the release notes are tied to each section? When a person goes to the scheduling section they can read about changes to scheduling, when a person goes to the report section they can read about the changes to reports without wading through the scheduling items.

 

Agile is one of the newest methodologies for developing software. If done properly new versions are released frequently. The list of changes can overwhelm the users to the point they don’t read the notes. Usually release notes are tied to the version number. Click here to read what is new in version 2.1.3; Click here to read changes in version 2.1.4. This makes the assumption that users read and understand all the notes from previous versions. What they want is the ability to read the changes to the scheduling section in the last 3 months. Using a database for the release notes gives them that ability.

 

Some features are more important than others. Minor changes must be reported but can make it difficult to find the good stuff. With a database behind the notes the more important features can be highlighted so they are not lost in the clutter.

 

As with anything that touches the customers the release notes need to be tested to make sure they are understood by the users. Depending on the size and nature of your user community this can be simply one user reading and approving the notes or a full fledged focus group.

 

Of course the real test is if the new features get used. Page hits and keystrokes can be recorded giving insight into what was understood and what needs to be clarified. The unused or misused areas point to unclear notes. This is valuable information that can be used to improve the product and future release notes.

 

Finally the release notes should be part of the feature request system. It is far easier to write clear notes if the underlying reason for the software change is known.

 

Release notes are just as important to the success of the product as the product itself. Clear flexible release notes can add to the satisfaction of your product.

© The Next Edge, LLC All Rights Reserved.