When I came to Brain Traffic as Employee #4, communication was refreshingly easy. I could greet the entire company with just one “good morning.”

It was really different from the large corporation where I’d previously been employed. A lot of changes took place over the seven years I was there, but one thing never changed: Every annual employee satisfaction survey named communication as a top challenge.

Follow-up feedback to the survey results pointed to communication problems between departments. People just didn’t understand the goals or processes of other departments, which created problems when those things affected their work. And it made them crabby.

So I was happy thinking the challenge of poor communication was behind me.

Except that it wasn’t.

Feedback in a vacuum

I didn’t recognize it at first. But there it was in the feedback for projects from large companies. Reviewers we’d never met requested—even demanded—changes that seemed all wrong. For example, they’d turn our succinct, tight writing into ugly, awkward run-ons filled with jargon.

Sabotage? Well, no. More likely these reviewers don’t know what makes good web content and why. They’re involved only because they’re subject matter experts, and their subject is appearing on the site.

If our internal contact does a good job explaining the goals of the project to their internal partners, then this problem may be averted. But sometimes there’s a mentality that says, “You don’t need to know about the web project and its goals. Just make sure the information is right.”

And there it is: poor communication.

The solution is in the meeting

So here’s what we do at Brain Traffic to combat this: At the very beginning of a web project, we have a kickoff meeting with everyone. That means everyone who is going to submit, review, and approve content.

At this meeting, we introduce the what, why, and how of good web content. We explain why web writing is different from print writing. We talk about the basics of good user experience. We reassure them that our intent is not to one-up, override, or otherwise disregard their input and concerns. We help them see, from the vantage point of the user, why concise content is way better than lengthy, complex jargon.

We’re not saying this approach solves all communication problems throughout the web content development process. But it has really helped us:

• Set expectations
• Engage content stakeholders
• Uncover questions or concerns about scope or schedule before everyone’s committed
• Identify other content providers or reviewers who’d been overlooked before
• Connect with people in person so that they know there are actual human beings writing their content and receiving their feedback

Think it’s too hard to get everyone together at once? Then hold a series of meetings. Get people on the phone. Try as hard as possible to engage everyone who’s going to touch the content as early as possible in your process.

Believe me, it’s easier than undoing (and arguing about) uninformed feedback and revisions in the 11th hour of your project.

What do you do to keep your content owners in the loop? Let us know in the comments.