As a user, I like release notes that tell me new features exists that I can explore, and/or tell me which user-facing bugs were fixed, so I can try using the feature again that I’ve been avoiding.
What I absolutely hate is the generic release note that seemed to come about with agile release schedules. Notes like, “bug fixes and performance improvements”, “Thanks for using <app_name>, we make regular improvements to ensure your experience is top notch”, or “We update our app often to <insert_marketing_taglines>.”
This tells me nothing and makes me less likely to bother reading any release notes at all.
I absolutely agree, and I really enjoy it when they show me what new things I can do with this change and how I can do them. Lately, Dia browser and raycast handle this nicely. I think most companies should base their strategies on this.
This will keep existing users on the app for longer. If you're a project manager or manage an app, this is definitely something you should care about.
Also, I'm trying something out here because I saw a loophole, let's see how it goes :)
I couldn't agree more. Release notes like that are informationally identical to a release note that just says "New release."
I use release notes to help me decide whether not to update to the new release. I would prefer that no release note is made at all over that kind of thing. At least that's being honest about not wanting to say what the changes were.
What bugs were fixed? What was made faster? If I was experiencing some bugs or slowness, I would be happy to see my issue may have been addressed in the release. If it says the issue was fixed, and I still see an issue, that’s a reason to send some feedback again.
As a user, I like release notes that tell me new features exists that I can explore, and/or tell me which user-facing bugs were fixed, so I can try using the feature again that I’ve been avoiding.
What I absolutely hate is the generic release note that seemed to come about with agile release schedules. Notes like, “bug fixes and performance improvements”, “Thanks for using <app_name>, we make regular improvements to ensure your experience is top notch”, or “We update our app often to <insert_marketing_taglines>.”
This tells me nothing and makes me less likely to bother reading any release notes at all.
I absolutely agree, and I really enjoy it when they show me what new things I can do with this change and how I can do them. Lately, Dia browser and raycast handle this nicely. I think most companies should base their strategies on this.
This will keep existing users on the app for longer. If you're a project manager or manage an app, this is definitely something you should care about.
Also, I'm trying something out here because I saw a loophole, let's see how it goes :)
I couldn't agree more. Release notes like that are informationally identical to a release note that just says "New release."
I use release notes to help me decide whether not to update to the new release. I would prefer that no release note is made at all over that kind of thing. At least that's being honest about not wanting to say what the changes were.
But what if that release really only included bug fixes and speed improvements?
What bugs were fixed? What was made faster? If I was experiencing some bugs or slowness, I would be happy to see my issue may have been addressed in the release. If it says the issue was fixed, and I still see an issue, that’s a reason to send some feedback again.