Great Expectations, Part Twelve: Patch Notes
By Sanya Weathers
Patch notes are a part of expectation management that won’t even be noticed by the vast majority of your customer base. If you put the notes on your patcher, build in a metric to determine how many people actually scroll through the notes before hitting the play button. If your percentage of the user base reading the notes breaks into the double digits, congratulations – your community is highly invested in the behind the scenes aspect of your product, and you can harness that in untold ways.
This article is for everyone else. Most people do not read patch notes… but the ones who do are your evangelists, your early adopters, and members of your fan media community. Handle the notes the right way, and the right people will have an expectation that you are an honest, forthright company committed to good communication.
Let me say before I really kick off that doing patch notes the right way is its own reward. True internal documentation often falls to the bottom of the priority list. I have worked on many, many MMOs and social products at this point, and I can tell you that every one of them hit a stage where the patch notes were the only surviving documentation available after the original team members left the company.
So how do you do patch notes right?
– Full disclosure. Document everything that changes in a product, including the things you think the users won’t notice. They will notice. They are playing it more than you are.
– Explain how things have been changed. Don’t just write “adjusted” or “changed.” Experienced consumers know that’s always a code for “nerfed.” Earn points with these core users by saying which way you made adjustments, and by how much. The rule of thumb is that if it can be reverse engineered by a customer, it will be, so you might as well put it in the patch notes.
– If you’re obfuscating anything, just say so. You are entitled to keep back information that you believe would give an advantage to hackers and exploiters. Simply say so when you’re holding back anything, rather than pretend there’s nothing there. Food manufacturers have to put their ingredients on the list, and when they get to something they don’t want to disclose, they put “assorted flavors.” Same principle applies.
– If you make edits to the notes after publication, say so. Ninja edits are not only not cool, but stupid in an age of net caches and RSS feeds.
– Involve Community in the patch notes process. I don’t mean “hand the notes to those people to post verbatim.” I mean rewrite and clarify according to the feedback you receive from that person, because he knows more about how users will read and react than the production team does.
– Show the notes to your internal testers, and perhaps a core of volunteer players before mass distribution. I can’t count the number of disasters averted because of this step, but let’s just say that without this particular step, I’d have switched careers ten years ago to something safer. Like shark dentistry.