Communicating Change to Your Users

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.

Even things that are broken or complicated become things some customers want to protect from change because they’re familiar with the intricacies of how those things work.
— From ReWork by Jason Fried and David Hansson

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:

  1. In Advance – Communicate about the change before it happens.
  2. In Context – Communicat the change in-app, when ( andwhere) it happens.
  3. 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.