RSS
Twitter
Facebook
E-MailHow to Make Changes to Your Community (without the Backlash)
ren asked: “What [do you] do when upgrading to new software causes a downturn in user engagement? How [do you] get it back?”
Thanks for the question, ren. For me, it relates to the general issue of change on communities and what you can do to make your changes more meaningful and widely accepted by your community. That is what I am going to cover in this article.
So that we stay focused, I am going to assume that you have given the change a lot of thought and have determined it to be worthwhile. If you have a staff, you have also asked for their feedback and improved the proposed change to a point where you are excited about it and are looking forward to rolling it out.
Limit Surprises
When you are rolling out meaningful changes to your community, it is generally a good idea to ensure that surprises are kept to a minimum. Members shouldn’t be surprised by a new design or a software conversion. They should have some idea that it is coming.
You don’t want to announce something, only to fail to follow through on it. So, wait until you are sure it is happening and then start preparing people, mentally, for what is coming. One of the reasons that people reject change is if they don’t know if it is coming or if they are shocked by it.
Explain the Benefits
You can do better than just letting people know what is on the way, you can tell everyone why you are making the change and why it is beneficial. You can also give previews and explain what is on the way, in further detail. You can tell them what is cool about it and why you are making the change.
Your goal is to get others excited about the change, so that they are anticipating it – not dreading it.
Get Feedback and Improve the Change
Perhaps the single most impactful thing you can do is to make your members a part of the development process. You can post previews of the changes or the design and ask members to offer their feedback. You can do this with the entire community or with a special group of members.
By making them a part of the process, you are giving them a sense of ownership in the change. More importantly, the feedback is usually very valuable. Your members use the site constantly and they are in a great position to share with you the experience that they enjoy. Allow them to help you make it better.
Make it an Event
Speaking of anticipation, if the change is big enough – make it a historical moment. Give it a day, a time and a countdown. Consider allowing people to RSVP for it, maybe even host a live chat.
Dealing with Backlash
All of what I have said so far is all well and good, but it is best to do those things before you launch the change. Let’s say you already have and the response is not good.
Generally speaking, with a large scale change like a redesign, that has been planned over an extended period of time, I would recommend against doing a straight reversal and going back to what you had before. Instead, I would focus on improvement of what you have launched.
Understand that sometimes, not always, the people who don’t like the change are a small (possibly vocal) minority. It is important to weigh this. That doesn’t mean that their feedback can’t help you, though. Just don’t make any rash decisions.
Even after you’ve launched, you can still explain the benefits and seek feedback. In ren’s case, it might be worthwhile to identify some members who have not visited as much since the change and ask them for their thoughts. Give that feedback some though and apply it as appropriate.
Thanks for posting Patrick. We’ve done as you said and also taken members’ feedback on board. Where possible, we’ll make some tweaks which genuinely improve the form and function.
Hadn’t thought of contacting lapsed members, thanks
Thanks for the comment, ren. I’m glad that it was helpful! Best of luck and thanks again for the comment that prompted this post!
Sincerely,
Patrick
The vast majority of changes I’ve made to my board have been incremental, and so I tend not to get any gripes.
However, there have been two specific changes that attracted an uproar: Visual redesigns of the forum index and topic posts (viewtopic.php in phpBB).
My development thinking is the reverse of the recommendation in this post, for better or worse. I plan and think through my designs pretty thoroughly based on my own web development experience and what I think will work. Then, I roll it out and make my users use it (as in “Eat this dog food, grunt!”). :) Seriously, though, you can’t get better feedback on a change than if users have to actually use it.
Then, in the unusual case I get gripes, I actually read them and fully consider them. I don’t go back to the way it used to be, as I wouldn’t have made the changes without a reason. I search in their comments for clues on how to make the redesign better, then I quickly implement changes based on those clues. This approach has worked for me so far.
Usually, the gripe lays along the lines of:
1) I can’t do (or think I can’t do) what I used to be able to do. (Or, they may have been misusing the original thing, and so direct them to the thing they should have been using instead.)
2) This isn’t as convenient to use as before. (The expectation of convenience is as American as apple pie, so don’t shortchange a comment like this.)
3) Things are arranged so differently that I don’t think I can get accustomed to the new design. (Maybe consider some minor backward adjustments if it doesn’t destroy what you’re trying to accomplish with the new design.)
4) I don’t want to see this new thing, or new aspect of a thing. It’s clutter or a distraction to me. (Consider creating a user preference that doesn’t display that thing.)
While you can’t always expect users to tell you directly how to make it “better”, you can detect this information from the gripes themselves if you think about them for a while.