RELEASE NOTES REVAMPED
SCENARIO
- RN is the only artifact that communicates updates of the Application.
- RN was written by Customer Success using the same title as the bug's support ticket.
- RN was a list of bugs with unclear descriptions.
- The content was difficult to understand.
- RN had no defined tone of voice.
- Unfortunately, RN presented low adherence from users.
- The resource where the RN was published is a small beacon within the Application.
CTO REQUEST FOR INTERVENTION
- UX Writer to adopt the RN.
- The objective was to write an easy-to-read and understand RN.
- RN should not provide information as of a User Guide.
- RN should be helpful for the first-time user.
- RN should reduce the gap of understanding of the solution.
- RN should tell a story.
- RN should engage users to read the content.
benchmark analysis
I compared embedded notifications and portals with Release Notes publications from Miro, Adobe XD, Google-Firebase, Microsoft Office Updates, Oracle Database, and Google Cloud.
BEST PRACTICES
Plain Language Approach
I suggested adopting Flesch Kincaid's Reading Score based on UX Writers' best practices. To avoid giving a sense that people can't understand our content without higher education. I suggested keeping this readability level as a definition only for our Design team.
We established Plain Language guides to achieving clear and easy-to-understand language. Our objective is to understand our in-product and release notes content the first time they read it.
Results
Organization by Module and Color
Content Taxonomy: I reorganized all content to make it easy to find. Grouped by Module to facilitate searching, so the user would identify what features matter to them.
Color for Types: We performed accessibility analysis to identify colors that appropriately differentiate bug Fixes from product enhancements as New features.
