Tag: ux writing

Tips for Writing App Release Notes

The iOS, and I assume Android, platform provides us with a few precious characters for each release. There’s no guarantee a user will read them, but, if they do, you had better make sure that you’ve treated that space with the utmost of love and attention and filled it with amazing words for your users!



Will anyone read them?

Like this page, maybe, maybe not, but the better question is:

How will I show the user that I genuinely care about their experiences and goals when using my app?

So what do I write?

This is a good time to think about what action you want to invite the user to take in this revision of the app. Think about their experience. What action are you enabling them to do? How does the new functionality further your users’ goals?

Can I use humour?

It often depends on your voice and tone guide (if you have one), but irrespective of that, there are still some guidelines you can use.

  • Don’t belittle the user, ever

  • Don’t downplay a bug fix with humour, especially one that has caused a lot of challenges

  • Be careful of localisation, humour rarely translates well

  • What sounds funny in your head might not be funny on paper

  • Stay away from stereotypes, they never end well

How much detail should I go into?

I think some writers struggle with this because we all love words. However, by prioritising and layering the information you can give your app shiny release notes that your users will get value from (which will give you a warm fuzzy feeling too).

You get a couple of lines to tell your user why they should click more, make it count!

The Important Stuff

  • This is the bit of text the user can see without scrolling irrespective of the responsive display.

  • This should be the information that is most important to your users.

  • Don’t put placeholder or arguably pointless text here like
    “Thanks for using the app!”
    “We’re always looking for ways to make things better”
    “ We release every two weeks!”
    “Thank you for your helpful feedback”
    “Bug fixes” (we know you fix bugs)
    That’s precious space you’re filling with words that have no value to the user or your app!

Questions to ask yourself:

  • What is the one thing your users will care most about in this release? 
  • What action do you want to invite them to take?

Examples



Wahoo Fitness does this really well. Right at the top, they list chunky new functionality (who doesn’t love an integration?) and there’s more!



tips app release notes wahoo more.png

‘More’ Additional Detail

This is still contained within the app release notes but can only be seen by scrolling or clicking ‘more’.

Questions to ask yourself:

  • How does the new functionality help them achieve their goals?

  • What have you done to smooth the experience of the app?

  • What did you fix for them, specifically?

Staying with Wahoo Fitness, clicking ‘more’ tells you what’s been updated and improved. The information is likely prioritised according to the user’s needs and provided in a succinct and clean way.



tips app release notes telegram.png

‘More’ Additional Detail Continued

Another app that does this very well is Telegram Messenger. It is nicely formatted and spaced. In addition, it has been written with user goals in mind.



tips app release notes trello.png

‘More’ Additional Detail Continued

And lastly, I want to give a shout at to Trello because I think someone who really cares about the users wrote the release notes (as you might expect from an Atlassian company!):



tips app release notes pluralsight.png

Everything Else

This is right at the bottom of the text and is usually 1–2 lines that can signpost the user in case they have another query.

Questions to ask yourself:

  • Is there any other relevant release information such as compatibility?

  • How can the user get help, support or contact information?

One company that I think nailed it is Pluralsight. They’ve given the most important stuff first and followed it with what they’ve improved. They’ve given details about the bugs and signposted the user to an email address if required. Nice work!

Summary

  • Write with the user goals in mind, always ⚽

  • Give the user the right level of detail in the right place at the right time ✍️

  • You have limited space, make every character count (check out your voice and tone guide) 🔡

  • Consider signposting the user at the end of your app release notes ➡️

  • I personally think we can do away with stating things like “bug fixes” unless you’re going to give details on which bugs. All software companies fix bugs 🐛