Growing Happy Users–One Customer at a Time
Technical writing is a profession in transition. The way companies think of, use, and manage the people who help users make sense of and use products is absolutely changing. A lot of companies have started to use the term “information developer” to describe their technical writing positions. I don’t really care what label the profession chooses for itself, but I do know this: if technical writers don’t transition more than their job title then they will be missing out on a huge opportunity to move from the “gotta do it” category into the “can’t live without it” one.
It’s the Community, Stupid
————————–
Three years ago the value of a strong customer community was not as immediately obvious. Today, however, there is no doubt that if you can transform your passive users into engaged users you can reap significant rewards.
Consider the difference between a passive and engaged user. A passive user is typically only a consumer of company resources (aside from the initial purchase of the product, of course). An engaged user–someone who follows what you have say, gives you feedback, and interacts with a community of fellow users–is in contrast a measurably positive force for your company and product. My personal estimate is that the value of an engaged user is worth at least 10 times that of a passive one.
Having engaged users can bring tremendous benefit, but for the company trying to build and sell product there must be a deliberate effort to encourage the establishment of a community. This is not without a cost. These types of users demand certain things that they’ve become accustomed to across the web. Google has trained them on a specific way to find answers and social networks are now training them on a new method of online interaction and feedback. Put simply, these users expect to be able to find what they need and, perhaps more importantly, they expect to be heard.
Social Documentation
——————–
Unfortunately, for most companies this can be a huge problem. It requires a huge shift in the way documentation is created, edited, published, and revised. Should writers be free to simply revise a paragraph at the behest of a comment from a user without waiting for a new release of the product? How do you manage and integrate user-contributed content with the “official” documentation? Should your technical writers also be bloggers–communicating with users in a less formal, more frequent way? The issues are numerous and go well beyond what I could list here.
A daunting problem is that the concept of the traditional manual slowly fades away. A product’s documentation is becoming much more organic–growing and shrinking, almost living, as the product and community around it evolve over time. This is a good thing, and is part of the engine that motivates your users to interact and stay engaged with the community.
The days of the 400 page PDF that is the user’s manual are dying a slow death, but there is no doubt it’s happening. One of the consequences of this is that the tools that writers use to create, manage, publish, and revise their content must change as well. Engaged users are demanding: they want wikis, screen casts, blogs, forums, and more–all uniformly searchable and each beckoning the user to come closer and engage in a deeper interaction with the company if they so desire. Got a question or comment about the how-to article you just read? Ask it! Need more information about the screen cast you just saw? Request it! Figure out a complicated part of the product and you want to share your experiences? Write it up and post it! This is hugely valuable and it means that the changing role of the technical writer will be to not only create content more quickly and for more consumable mediums, but they must also be prepared to directly interact with the user and incorporating the feedback from those interactions into future documentation.
Happy Users
———–
Achieving this is hard, but the potential to create a virtuous cycle is enormous. Engaged users help your community grow and their happiness is infectious. 
Happy users are advocates and they make for a powerful force in helping you define, build, and grow your products.
There are pitfalls. If you don’t engage the community openly, honestly, and with transparency they an be a vengeful force. Work hard to build the community, but work even harder listening to what they have to say. Users who feel engaged will forgive a lot of sins, as long as they believe you’re operating in good faith.
Are you a technical writer or information developer? We’d love to hear your thoughts and feedback on this post. Take a minute to leave a comment and let us know what’s on your mind.
-->