Transparency and Authenticity Lead to Trust in Information Sources

Friday, July 17th, 2009 | Technical Communication, Writing Theory & Practice

As noted in my last post, people can come to trust sources of information through the source’s authenticity and transparency. These are two very closely related attributes. To set the stage here, I’m going to put a couple of definitions forward.

According to Dictionary.com, transparency in this context is “full, accurate, and timely disclosure of information.” Authenticity is “The quality or condition of being authentic [nothing like defining a word using the word], trustworthy, or genuine.” So being authentic is “Conforming to fact and therefore worthy of trust, reliance, or belief”; the usage guideline indicates that the word suggests a “sense of actuality and lack of falsehood or misrepresentation.”

Transparency lends the picture that there is nothing being hidden behind the information source. Everything is in plain view. The information can be easily obtained, and it’s not skewed to fit some ulterior agenda.

Don’t Cross the Line

Can I tell you that I don’t like it when documentation tries to sell me something? It lowers my respect for the information source because it feels like they’re taking advantage of me in my vulnerable state. I’m trying to get assistance, and I’m being clobbered with marketing! If I were to think about it a little harder, I’d probably wonder whether the information source was completely forthright, or if they wanted me to know only enough to buy more. The Stanford study previously cited indicates that lack of commercialism contributes to trust.

While tech comm and marcom may share content, their motives are quite different. So one way to be transparent and authentic is not try to sell other products in the documentation. Don’t extol their virtues. Just state the facts. If Software A shares content seamlessly with Software B, talk about how the user can make it work, but avoid playing up how great the software is because of the feature and suggesting the user buy Software B.

It’s like the woman who called me and said I’d won a drawing for a free carpet cleaning. I agreed with her on a time because I figured it wouldn’t hurt. (No, I’m not in the habit of accepting free stuff over the phone.) But when she showed up, it was to demonstrate a $3000 whiz-bang vacuum cleaner. She did some cleaning, but of course my wife and I had to sit through her pleasant but calculated conversation about the product. She was nice, but she hadn’t been forthright. I thought I was getting a service, but instead I was getting a sales pitch. And when people use the documentation, they’re looking for service. We should avoid crossing that line.

Full, Timely, and Accurate

Let’s take these one at a time.

Full Disclosure. We know that can’t turn the firehose on users when they come looking for information. They need just enough information to move forward. But are we then not being transparent?

Going back to definitions (I’m not one of those people who reads the dictionary on vacation, I promise), full disclosure is the imparting of relevant information. So it’s not the entire dump truck.

I believe every piece of relevant information has its place, and different information is relevant at different times. The trick is to direct users to the right piece of information at the right time. I’m becoming a fan of context-sensitive help because, while it’s trickier to implement than a static default help topic, it gives users a better place to start. Descriptive headings and links to related information can guide them further. All relevant information can be available, but it should be easy to blast through to the right piece. Which takes us to the next item.

Timely Disclosure. I edited a manuscript once where, in the narrative, the author would describe what was happening, and then a paragraph or two later clarify some of the events. I edited the text to place all the relevant information where the situation was first described so that the reader wouldn’t have to revise his original imagining of the story.

Similarly, technical information should come in the proper order. Worse than having to re-imagine a story’s events, placing steps, notes, warnings, and conceptual information in the wrong order can put the audience in a worse position than they were when they came looking for assistance. I found recently that usability testing of documentation helps find the right order for things.

Accurate Disclosure. This can be the really challenging one. It gives rise to the discussion of whether to document how it’s supposed to work versus how it really works. It also demands that deadlines be met. I’m one to prioritize my tasks and update the most important documentation first. Small things end up waiting.

A user of one application sent a feedback email noting an inaccuracy in the help. It turned out that the application wasn’t behaving the way it was prototyped to, so he actually identified a bug in the system for us. But I sent him a reply indicating that we would address it.

I totally understand the feeling of frustration that results from having the instructions tell me to click something or choose an option that isn’t there. I know it’s not there; I checked. Four or five times. Just to make sure I wasn’t crazy.

And the trust diminishes.

An Unfettered Voice

People trust bloggers when they’re real and straightforward, when they speak their minds honestly because they’re not under some obligation to do otherwise. However, we technical communicators are under some obligation to the entity that pays the bills. And technical communication isn’t about observation or exposition. So how can we turn that trust for independent, forthright thought and voice to our advantage?

Writing a product blog is one way. Visiting user forums is another. I like release notes for the opportunity to be honest about what’s not working and how users can get around it. I also have the chance to interact with users sometimes, especially when they are in-house and local.

Something occurred to me earlier this week as I was listening to one user’s frustrations about the transition from a legacy app to a new web app. I owe my job to the development of this group of applications because I was hired initially to work on a specific one. Those applications are a good thing for me.

While this is a positive concept, I’m considering it in this context and realize that I’m not under an obligation to paint a rosy picture about the software. I’m there to give the users the means they need to do their jobs. I’ll leave it to their managers to talk about how much the system will benefit them or how much they’ll like it. Mine ought to be a voice of plainness, leaving out all persuasive devices (except warnings, of course). A “product evangelist” is one of the last things I want to be. That’s one of the things I like about non-commercial software. But it is nice for the audience to have a positive perception of it all the same.

A Recognizable Voice

It may be something of a psychological trick, but I like to use questions in the audience’s voice in certain cases to help them recognize the right information. For example, in a set of release notes, we encouraged the users to upgrade to the next version of Internet Explorer (which is the default browser for our corporate desktop configuration). I included a sidebar entitled, “What Version of Internet Explorer Am I Using?” Phrased this way, the heading helps a reader instantly identify whether this is a piece of information she needs.

For this reason, FAQs are highly beneficial if they contain questions users are actually asking. They see those questions and ask them in their own voices; as a result, they identify with the information and its source.

See what you can put in a user’s voice and in a realistic voice. They’ll more likely recognize it and see you as a helpful peer.

Wrap-Up

To be trusted as an information source, it’s good to remember the keys of being transparent and authentic. Don’t hide anything. Don’t have ulterior motives. Be as independent as possible, and make your voice synchronous with the audience’s. As technical communicators, one of our primary responsibilities is to look at things from the users’ perspective—therefore, we ought to explain and instruct the way they would.

Previous: Keys to Being a Trusted Source of Information
Next: Consistency Leads to Trust in Information Sources

Share This