“Lately we’ve been asking ourselves “what else could we do to improve developers’ lives on the internet?”. Jeff’s original announcement of Stack Overflow said this:
There’s far too much great programming information trapped in forums, buried in online help, or hidden away in books that nobody buys any more. We’d like to unlock all that. Let’s create something that makes it easy to participate, and put it online in a form that is trivially easy to find.
Stack Overflow has made all of that a lot better, but there’s one area that is still hanging around: Documentation. Just like Q&A in 2008, Documentation in 2015 is something every developer needs regularly, and something that by most appearances stopped improving in 1996. We think, together, we can make it a lot better….
…We’re hoping we can improve documentation, not just move it under the stackoverflow.com domain.”
It will be fascinating to see how this project progresses – what issues they encounter, how they tackle these, and if the solutions work.
Google’s Riona MacNamara presented at the Write The Docs North America conference on “Documentation, Disrupted: How Two Technical Writers Changed Google Engineering Culture“. In the video of the presentation below, Riona explains how she worked with a small team of writers and engineers to build a documentation platform in six months that is becoming a part of the standard Google engineering workflow.
This was a surprise, as Atlassian has been a strong advocate for having user comments appended to user documentation. Sarah Maddox, when she was working at Atlassian, posted the reasons why the company encouraged comments on her personal blog:
David Farbey wrote a semi-existentialist post on the challenges for technical communicators yesterday. I’d like to look at the issue in a different way, by looking at the big questions in technical communication today. The answers to these questions (which may be decided by people outside of the profession) are likely to affect the future direction for technical communicators.
We’ve been on the road in recent days and weeks, visiting different documentation teams, and we’ve found there are distinct signs of change. In this post, I’ll look at how we’re starting to see the workflow for creating User Assistance beginning to change.
We found many documentation teams overstretched and starting to be asked how they could create content for new products that were coming along. Some organisations have decided they can only deal with this extra workload if they rethink the workflow for how content is created.
Last night I saw presentations at the Content Strategy London Meetup from Rob Hinchcliffe (a community strategist), and Sara Treewater (Content project lead for Citi Private Bank’s Web and Mobile team) in which they both mentioned relationship marketing and how it was influencing content strategy.
If your marketing and sales strategy focuses on developing a relationship with your customers and prospects, it makes sense your pre- and post- sales content (such as user documentation) sustains and builds relationships as well. Joe Gollner has called this “relationship content”. This may mean giving people an opportunity to comment, and supplement, your user documentation. In other words, moving from a monologue to a dialogue.
This can be challenging for organisations, particularly for those where there are compliance and regulatory considerations. However, there may be little choice but to do this. Rob Hinchcliffe said in his presentation that, today, content is everywhere. There are unofficial information sources where Google will direct users, if you do not provide content that’s relevant and useful.
If this relationship goes further, you can gain a significant insight into how each individual customer and prospect behaves, and start to disrupt your industry sector. We discuss this in our latest post on the STC’s Notebook blog (we’ll post a link once the post has been published).
You’re welcome to join us on our upcoming free webinar, “The changing nature of content”, which will be held at 7pm (GMT+1) on 24th April 2013.
In recent years, technical communicators have focused on improving User Assistance through new technologies and systems, with the assumption that the nature of the content the tone of voice, the writing style should remain the same. In this free webinar, sponsored and hosted by Adobe, we’ll investigate whether the tried and tested writing methods from past decades still make sense today. We’ll look at the reasons why some organisations are “breaking the rules” with the User Assistance they provide.
Mozilla’s Janet Swisher had a number of useful tips at Technical Communications UK 2012 on how to encourage user generated and community based content:
People contribute because they want to learn something and for personal growth. You need to recognise this work.
Crowds aren’t smart, communities of peers are.
Create a community about the topic of interest, not solely about your product. For example, create a community on camping, not on your brand or your camping products. Solve common problems, rather than niche ones.
Community based content is where contributors share a common goal. User generated content is often “all about me”.
You can review contributions before they go live on the site, or review them after they have been published. You need to choose the approach that works for you.
Having a forum where customers can express their views can be deeply uncomfortable for organisations. Organisations tend to encourage what Leon Benjamin called a “red zone/green zone mentality”. The green zone is safe and trustworthy and within the organisation. The “red zone” is anything outside of the organisation – and can be seen as risky, dangerous and untrustworthy. Yet the reality is that most people get information from outside the organisation (from the red zone).
Users will express opinions and publish contributions on other sites, if you don’t create your own forum. If you create the community, then you will be more able to control the accuracy, authority and accessibility of and to this information.
Having said that, sometimes you need to publish to areas outside of your control. For example, issuing your manuals via Amazon Kindle might expose you to user reviews. They could say they hate it or that they love it. That public feedback can be daunting, but remember we all have our filters to assess the information.