Back in the day, when a startup was going to ship a product, they would hire a writer (or a team) to create a suite of documentation. They’d hire a marcom person to create datasheets and whitepapers. They’d hire someone to create a website. Most of the time, the people they hired were specially trained to create content.
Today, startups are creating content in a much different way. Instead of hiring a technical writer to create procedures (for example), the startup puts up a wiki and various people in the company who have jobs other than writing add content to the wiki. I’ve seen content created by software developers, QA testers, technical support engineers, field service engineers, and more. Lots of content being created by lots of people, none of whom write content as their primary task, and many of whom have never been trained on how to write.
It is an interesting phenomenon. I can see why many companies think they are saving money doing it this way. Why pay a writer $100,000/year (give or take) to write, when you can just add pieces of the writing puzzle to the job requirements of a bunch of other people.
I call this type of collaborative content creation internal user-generated content (I-UGC). I call it internal so as not to confuse this type of user-generated content with external user-generated content. External user-generated content is created by people external to the company. Usually we call these people the community. It is the community of product users who begin asking and answering each other’s questions. I will talk more about external user-generated content in another post.
For now, I want to take a look at the pros and cons of I-UGC.
As I mentioned, most companies use collaborative I-UGC because they believe it saves them money. In addition, here are some of the other positive things that come out of the I-UGC process:
- Content is written by people who are creating the product, which should lead to more technical accuracy.
- In a collaborative environment, content creators get to see what other people are writing. This often produces interesting conversations about how the product operates, because one person doesn’t necessarily know what another person is working on.
- Content can be updated very quickly.
- Some people believe that the sum of the collaborative process is worth more than the parts.
There are probably more benefits to I-UGC and I encourage you to share them in the comments.
Admittedly, there are also some negatives to the I-UGC creation process:
- Just because the content creator knows the technology does not mean that this person knows how to write about it.
- It is difficult to maintain the same voice and tone from writer to writer.
- Sometimes people who are too close to the product leave out important information that someone who doesn’t know the product would need.
- The content can end up being very disorganized and hard to follow.
- Even if the content is technically accurate, that doesn’t make it usable by the customer.
- It is almost impossible to translate I-UGC because of all the factors listed here. Translation can end up being a very time-consuming and expensive event.
- If content creation is not the main job of the person creating the content, that content becomes an after-thought. It can get short-shrift and be done in a very rushed manner.
Enter the Content Curator
As I-UGC is starting to take hold at a number of companies, there is a new role in the development process for someone who is a curator. A content curator is a person who acts as the central clearing house for all of the content that is published. Ideally, this is someone who is a skilled editor with a specially-trained eye for organizing and rewriting content into a unified whole.
Content curation tools are starting to proliferate. Most of them are used to sort through the hordes of data on the internet to present specific topics of information in an organized and coherent way. In fact, I curate a website on global-ready content. Applying these tools to your intranet or to your website that contains I-UGC created information could be extremely handy.
I am pretty old school. I think that writers should write, developers should code, QA testers should test, and technical support engineers should solve customer problems. But I cannot change the way companies decide to create their content. I can just offer my opinions and think of ways to help.