Over the past couple of years (since Sally stopped writing our release notes) we’ve worked hard to make them more useful and also well integrated into our delivery process.
But talking about them with @Rachel and @sauloperez in BCN, we believe they could be even better.
So I’m creating this topic for us to gather great examples of how other software companies communicate to their users about the changes they implement, that can inspire us to start doing ours in an even more user-friendly way
Feel free to add examples to this topic if you know of any that you believe are great
Their releases seem to include a particular feature alongside of the bug fixes and small improvements.
I really like how they use screenshots and videos to explain how the new features work. And they link to further information where they have it (e.g. userguide).
Slack have in-application notifications about changes to their software that you can access via the main menu. This section has a small blurb about the change and then links to a blog post when more detail is available.
I really like the way they don’t talk specifically about releases, but just focus on what the user can now do and don’t do a big list of things but break them out into their own snippets. And they don’t necessarily talk about bug fixes but more about interaction/feature changes.
Another great example. Figma has a https://www.figma.com/whats-new/ where they focus on the most relevant feature changes with lots of images an explanations, linking to docs. At the same time they also have (and link from what’s new) a https://figmareleases.blogspot.com/ where they list the relevant changes included in each release but still described in a user-focused way with gifs and images.
In these examples, the things I think will work well for us:
integration of screenshots or animation - don’t have to be as fancy and perfect as some of these examples - just a simple screenshot is great
keep in mind who the communication is for - ie: primarily non-dev users I think - right?
keep an archive/history (like in the blog posts) of previous releases - since we should anticipate that users will not race to reach each one as soon as we put it out
but I guess we can discuss what we exactly want from our release notes given all these examples. Then, we’ll change our releases process accordingly. Let’s see what @danielle has to say.
The problem we have is capacity to do this thinking and change work alongside of everything else that people are doing. It needs to be prioritised in the pipe just like everything else (product management, roadmap creation, finding funds, bug fixing, performance work, API work, etc etc etc).
Does this fit in the ATAP world @rachel? I’ve purposefully steered clear of that world as I have trouble enough keeping up with all the other meetings and other stuff we have…but it’s a comms thing, but also related to the platform work. And the roadmap building work (which also isn’t on any to do list right now).
@danielle actually @sauloperez@Jen and me have an ATAP action of moving this forward so it is in the ATAP world.
At last ATAP meeting, Pau was still on holiday so we decided to move forward when everyone would be back and gave this a low priority. But I agree now we are actually in a good place to move forward and increase priority on this. Next ATAP meeting is Tuesday. Can you make it @sauloperez ?