Communicating Change to Your Users
Links, articles, and resources on the best practices in communicating about change to users of your apps, sites, and digital products.
Key Articles and Links
Stop me if you’ve heard this one:
- Q: What did the developer say to the users in the changelog?
- A: Minor bug fixes and enhancements.
Whoops, sorry, that’s not a joke. It is unfortunately common, though. Far too often, changes in software and websites are communicated to users with a cavalier attitude — if it all.
I hope that these resources (and associated presentation) will help explain why it's important to communicate clearly about change, why we often don’t, and how to do it better.
The big ideas
Change is a feature.
Software used to literally be shipped. On disks, in boxes, via trucks. Software updates were few and far between, and many apps (programs, as we used to call them) wouldn't get updated for years, if ever.
Today, software updates "ship" via terminal command, instantly, sometimes to millions of users at once. This means that change is the most critical feature of most modern software. Like any other major feature, it should be actively managed, thoughtfully planned, and clearly communicated.
Three moments to communicate change.
There's a lot to consider when communicating change to your users. This simple framework will help you remember the three most important moments to communicat change:
- In Advance – Communicate about the change before it happens.
- In Context – Communicat the change in-app, when ( andwhere) it happens.
- In Perpetuity – Publicly document changes for the long-haul, such as in a change log on a status site or a knowledge base.
The Communicating Change talk debuted at MinneWebCon and the Information Architecture Summit in 2012. I've also shared it at a few Meetups, and the 2015 Des Moines Agile conference.