We’ve already discussed how documentation can positively impact experience. I won’t revisit that reasoning again, but I think that it is relevant to this discussion simply because happy customers buy more stuff. In this post I want to look at one new reason: converting more customers during the buying decision.

Good Documentation Can Convert Customers

Certainly the majority of open source projects don’t write enough documentation, and more power to them because they don’t have to if they don’t want to. However, the projects that seem to bubble to the top (Linux, Spring, or Apache) all seem to have really great documentation. In the following section, we look at two positive examples closely.

Documentation helping commercial open source projects find more customers.

Alfresco builds an open source enterprise content management system. They are the commercial entity behind the open source project of the same name that sells services and support to customers who want a bit more than what the community can provide. Alfresco is an interesting example because they give their software away for free. Their value add is their knowledge and understanding of the product as well as the testing and certification they’ve provided around the open source code.

In the CNET article Open-source strategy: Documentation = dollars Ian Howells, Alfresco’s Chief Marketing Officer, states that 30% of their leads come from people who read their documentation and goes on to say:

[The] vast majority of our deals are fed by two direct sources: those who read our documentation and those who actually download and try our Enterprise code. Now, we also know that most of these people first start with our Community code (and often evaluate it for months, reading documentation and visiting our website in the meantime).

What does this mean? It means that if our demand generation software is telling us that someone has both read documentation and evaluated Enterprise, the odds of them buying support from Alfresco are huge. We want to be calling that prospect immediately.

Alfresco understands that accurate, informative, and helpful documentation gives them a competitive advantage and they’ve measured the impact. Take a look at this chart from the article showing time spent by visitors on Alfresco’s website:

The light yellow bits on the bar chart above represent time spent by visitors reading the documentation. Wow. This is a great example of how documentation can be a deciding factor in whether someone uses your product. When a user is deciding whether they want to invest their time in trying your software they will often look at the documentation asking themselves whether it looks like its worth the investment.

Documentation as the primary deciding point in selecting an open source project.

Developers are notoriously finicky about the tools they use. That’s why I picked this example from William Shields. William’s recent blog post highlighted his frustration JUnit’s horrible documentation. However, he found it difficult to switch because he had a good, if not perfect, understanding of how to use it. William goes on to say that a competing project’s documentation was so good that it became a deciding factor to motivate him to switch. He writes:

I am gushing like a schoolgirl over TestNG’s documentation. There are examples of how to integrate into different IDEs—not just Eclipse (my pet peeve as a diehard IntelliJ IDEA user). The user guide is detailed and extensive. There is even integration documentation for Ant and Maven as well as a migration guide for JUnit.

Documentation alone is reason enough I will in future choose TestNG over JUnit without exception where I have a choice.

JUnit and TestNG have very similar feature sets. Sure there are differences, but ultimately converting William to a TestNG user came down to the documentation. Why? Because good documentation removed frustration from William’s life, and that alone was the best “feature” TestNG could give him.

Let us know what you think!

We want to hear from you. How does your company value documentation? Is it a “check the box” task or is it viewed as a competitive advantage? Leave a comment below and let us know what you think.

Technorati Tags: CustomerEngagement, Documentation, TechnicalWriter, TechnicalWriting, UserEngagement, UserExperience

Within hours, I not only had an answer by email, but the company’s founder, Troy Malone, recorded a video response to my question. The response answered my question, and went on to offer additional useful information related to it–information I had not yet thought to ask for, but which will help me down the road.

Wow, that is pretty powerful. Certainly the fact that one of the founders responded personally is impressive, and it sounds like Troy Malone has made customer support a key tenet of the culture at Pelotonics. This is a great example of how positive customer points of experience have a lasting impact on a customer, and indeed can lead to a groundswell of positive after effects. Tony writes:

[The experience] was so good, and put such a stake in the ground for me in terms of productivity, that I have to share it here.

Tony is a happy user and this experience made him want to share that happiness with the internet. That’s outstanding for Tony, and even more so for Pelotonics.

Responsive Documentation

The video that Troy created for Tony is documentation. Specifically it answers a question about how to see a global view of tasks and milestones in Pelotonics. The answer wasn’t found in the documentation itself but was instead syndicated to a custom Ustream channel that the Pelotonics’ staff runs. Every day they are are standing by to answer questions. This is really cool.

Pelotonics understands that when users have a problem they want answers. The ideal situation would be for those answers to be in the documentation, but the next best thing is to get a customized response. I wonder, however, do these answers make their way back into the official documentation? Based on my initial search I don’t think the answer to Tony’s question is in the documentation yet, but I might just be missing it. If it isn’t, placing the videos into the documentation is a simple change that Pelotonics could make to ensure that this valuable video content is findable when users read the official documentation.

This Pelotonics example shows several key aspects of social documentation:

1. The answers are evergreen. They stay fresh. The continuous updates from the Ustream feed means that the documentation (if properly updated) could grow and change over time in response to customer demand for answers.

2. The content is syndicated. Pelotonics didn’t have to invest in a video on demand system or content distribution network to post rich video help content. Instead, they used the web and leveraged an existing video service.

3. Finally the answers are responsive. They are exactly what the customer wanted. The pre-written documentation represents a best guess at what a customer might need help with. This type of documentation is responsive to a real-time problem. There are several ways to do this. Pelotonics chose to use their custom Ustream video and chat channel to connect with real-time customer problems. Another way, perhaps less responsive, would be to view and analyze search analytics to see what search terms people are using to ask questions of your documentation. An even more appropriate approach might be to use Twitter as a direct, real-time connection to your customer’s problems. Whichever approach, the point is clear: one highly targeted answer to a real-time user question is more valuable than the entire documentation set.

Let us know what you think!

What Pelotonics is doing with video as a way to answer customer questions is intriguing. I’m going to try to contact them to get a more detailed view about the challenges and successes they’re finding with their approach to documentation and customer support. I’d also love to hear what you have to think about this topic. Do you publish videos as part of your documentation? How responsive is your documentation to real-time customer demand for answers? Leave a comment below and let us know what you think.

Technorati Tags: CustomerEngagement, CustomerSupport, Documentation, TechnicalWriting, UserExperience

Your documentation is a collection of answers to customer questions, and generally, customers have been trained to search before looking, meaning they likely won’t visit your support or documentation site before asking one of the major search engines their question. Studies have shown that users click on the top three links on search engine results pages 80% of the time and that users spend nearly 70% of their time reading the content on those pages. When a customer has a problem and finds themselves needing an answer to get out of a jam they will look to Google for help.

Remember that you want your company’s content to be seen as authoritative. You want to control and guide your customer’s experience, and the best way to do that is to ensure that they see your words, videos, and messages first. The easiest, most effective, and honest way to do this is by providing high quality content. Not doing this means that other people participating in the broader, untethered community (say, asking a question in Yahoo! Answers) might have the first word when your customers have a problem.

If your content isn’t authoritative and customers don’t find it first then you run the risk of allowing your customer in need to not have a positive experience. Frustrated users are bad, especially when they use the internet to tell everyone else how frustrated they are.

A Simple Case Study

Let’s look at a real world example. Skype is a company that provides Internet-based phone calls. They are wildly successful and a rather cutting edge company. Their support site is one of the better that I’ve seen. It is direct, to the point, has a pleasing experience, and provides intelligent results. Skype also does a decent job of ensuring that the content from their support site has decent SEO. For example, their URLs are semantic and pretty, no “topicId=731254″ here. That’s why this example is so important, because even a company that values customer support as highly as Skype can still get it wrong.

Assume you are a Skype customer and you’ve lost your password. You’re trying to figure out how to retrieve or reset it so you go to Google and search for ’skype lost password’. This is what you’d see:

In my book that’s a win. The first link is the exact help topic that you need and it contains the exact answer to your question. In your mind the Skype support site is now authoritative for this question and answer and the customer experience is great because you are not fighting to find the right answer. According to Google’s Keyword Tool there are about 400 searches for this keyword each month. Not bad, 400 users sent to the right place and given exactly what they wanted.

What if instead of searching for “skype lost password” I decided to search for what I wanted to do, “skype retrieve password”. These are the results that Google would give you:

The first two links go to Yahoo! Answers and the third link is the actual help topic with the answer, the one that was first in the results in our first query. The first problem is simple, there are a large percentage of users who will not go directly to where the answer is. Instead they will be sent to a question in Yahoo! Answers. Hey, no big deal, right? Wrong. The “answer” provided on the Yahoo page is incorrect. It links to the wrong place in the Skype support center, and instead of sending you to the answer it goes to the Skype support center’s homepage. This is by no means catastrophic, but as a customer you’re starting to get frustrated. Luckily Skype’s support center is modern and makes it easy for the customer to find what they want–the first topic under “Popular Queries” is a link to the right topic in the documentation; unfortunately, Skype is the exception not the norm.

What’s the impact, in terms of numbers here? Not bad, about 300 people search for “skype retrieve password” each month. Going from the statistics in the report linked above, that means about 210 people went down the wrong path through Yahoo! Answers rather than directly to the correct information on Skype’s site.

Well here’s where the wheels go off the bus. Suppose instead you simply search for “skype password”. There are about 40,000 searches each month for this term. It’s not clear from the search exactly what the person is trying to achieve, but there aren’t very many things one might be able to do with a password. Let’s assume 50% are trying to fix a lost password either by resetting or retrieving it. That’s 20,000 searches by people looking for this topic in the Skype documentation. This is what Google would give them:

No where on the first page is any link to Skype’s documentation. The first link is to Skype’s forum–that’s good–but unfortunately the content on the page is totally wrong. No help for the random user looking to retrieve their password. There is a link within the forum post to a place where you can ask Skype for help by opening a ticket, but unfortunately this link is also broken (like in the forum post from the previous search) and sends the user to the completely wrong place. To make matters worse there are links to unauthorized tools and users complaining about the password policy. Certainly you can’t control what other people say about you on the Internet, but if the Skype documentation topic with the answer was first in the results, then the click statistics would imply that any user looking for help wouldn’t even see those pages.

Remember, we are assuming that there are about 20,000 searches that end up in this dead end each month. That is unfortunate for the user, and damaging to the customer experience of Skype. Equally disappointing is that there is no excuse for this to be happening.

What Should Skype Do?

1. Optimize their most popular topics for more effective SEO. Skype already knows what topics are popular–they show them on the Skype support homepage. By investing a little time and energy into those topics they can ensure that users land on the right topic regardless of whether they search for “skype lost password” or “skype password”.

2. Manage stale content. Ideally stale content wouldn’t be a problem because your content, the most authoritative content, would be first in the search engine results. However, sometimes that isn’t possible. In the case of the Yahoo! Answers skype could easily leave an answer of their own that is more appropriate and linked to the correct page. Further, their own forums are providing incorrect answers. They should edit those forum posts to ensure that users reading them also know where the right answer is in the official Skype documentation.

Of course, Skype has a great starting point. They already have a nicely designed, full featured, and probably custom built help center. They don’t force users to make decisions about where to find an answer (Is it a knowledge base article? Is it a forum post? Etc.). Instead they place search front and center, giving the user an easy way to get what they need. Most companies don’t even have this so they find it overwhelming to think about the issues discussed in this post. Thankfully, there’s a company out there trying to make it easy for you to get all the great benefits of a Skype-like support center.

Let us know what you think!

We’re always interested in hearing what you have to say. If you’ve got an a question or comment please stand up and be heard. Leave a comment below and let us know what’s on your mind.

Technorati Tags: CustomerEngagement, CustomerSupport, Documentation, DocumentationSucks, HelpCenters, SocialCustomerSupport, TechnicalWriter, TechnicalWriting, UserExperience

Pogue’s column is titled “A Router So Complete, and Vexing”. He was generally positive on the idea of a combined router, home backup hard drive, and digital picture frame, but he wasn’t so happy that D-Link was the company building it. From his article, emphasis is mine:

The 685’s heart is in the right place. Its inventors have noticed that our high-tech homes are becoming cluttered with network-related gadgets and their associated cable creep. As long as people are going to buy all these different network gadgets, D-Link figures, why not combine them into one?

It’s the right idea. Unfortunately, D-Link is the wrong company to make it a reality.

Ouch.

So what went wrong? D-Link made the classic mistake of ignoring the user experience. In fact, David thinks you’d have better luck figuring out how to fly the Space Shuttle.

What I really like about this article is that David’s highlights of the failing of the user experience include the documentation. It is an excellent example of what I’ve spoken on about this blog before, namely that documentation should be a tool in the user centered design process and that the documentation is a valuable point of experience that can significantly impact a customer’s opinion of your product or company.

Above all — and this is the mind-blowing part — D-Link is selling this very complex piece of consumer technology without a single word of instructions for the features that make it unique…Isn’t it amazing that, after all these years, it still hasn’t dawned on companies like D-Link that simplicity sells? They still don’t get it: spending a little money up front — on hardware design, streamlined software, better manuals — would save a fortune in tech-support calls and store returns.

D-Link spent all their time engineering the product but forgot to educate their users on how to use the new features. Massive fail, and an unfortunately public one for D-Link.

Let us know what you think!

Leave a comment and share your opinion about documentation and user experience with us. We want to hear from you!

Technorati Tags: DocumentationSucks, TechnicalWriting, UserCenteredDesign, UserExperience

On the second day Joe Pulizzi gave a keynote presentation entitled “Please Stop Talking about Yourself: Marketing is now Publishing (and what to do about it)”.

I’ll summarize (although you should really click through the slides even though there is no audio available): the future of marketing is about original, educational, and entertaining content. Traditional marketing is littered with companies talking about themselves, but future marketers will create and publish uniquely helpful content to help solve common customer problems. By doing this, companies can establish themselves as the go-to, trusted, expert resource for their industry.

An Authority Crisis for Documentation?

There is most definitely a technical communicator identity crisis underway. Recent posts from online technical writers include:

• Tom Johnson’s thoughts on How to Avoid Extinction as a Technical Communicator.
• Anne Gentle on her concern about a Dangerous Future for Technical Writing.
• Ellis Pratt’s reaction to the implications of online research trends: The ‘Google or Death?’ choice for technical authors.

Three posts from well respected industry professionals in the span of one month, all dealing with a fundamental shift in an core product development profession. What’s going on here?

To put it plainly: documentation now has competition. It used to be that the published manuals from a company represented the sum total of available educational and troubleshooting content for a product. The appearance of the Internet began to change that in the 90’s as people turned to USENET, mailing lists, and other forms of online interaction to collaborate with peers and to solve common problems. However, with the rise of social networking and online communities wrapped in a very efficient Google (and now Bing) search experience there is now an alternative to wading through the piles of help content published by many companies.

Documentation now has to compete for the status as the go-to, trusted, expert resource for a product. Sound familiar? Marketing is transforming into a publishing effort, all in the hopes that a company can be seen as the definitive resource for an industry. The future of documentation is a microcosm of a bigger content revolution.

To a certain degree the identity crisis that technical communicators are facing is a consequence of the growing authority crisis facing documentation. Writers want their content to be useful, but they’re finding that users are finding answers somewhere else, resulting in a devaluation of the documentation. Note, I said they were finding the answer somewhere else, not the content. There is a very big distinction here, and it relates to the channels that are used to publish the documentation.

The majority of documentation today is published in one or two channels: PDF and WebHelp. This content is usually distributed on the corporate web site, after which the writers set to work on the next release. Users, however, are finding their answers in forums, on wikis, on Twitter, and in other communities where people share information. It’s not because the documentation doesn’t contain the answers, in fact in many cases the forum messages that solve a problem are either links to specific topics in the documentation or a summary of the content available there. The true problem is that of distribution, search, and findability.

Of course, for an overworked writing team getting the content out into PDF is a win, and even though many writers want to do more they simply don’t have support from the tools that they use daily.

Better Tools are Needed

On Tom Johnson’s blog entry that I referenced above there were two comments that I think are related to the root cause for this particular problem. First, the commenter, Gordon, noted:

I definitely think, as Ellis suggests, that our roles should be changing (should have been for quite a while). Partly I think we are too governed by the technology available in our own profession (we seem to tend to wait for the vendors) and partly because we still struggle to express the benefits of opening up information and embracing any/all new methods of communicating with the customer at a technical level.

and Tom replied with:

I agree that we tend to wait for vendors to supply the technology we need. If we technical writers were programmers, especially web developers, we would have much more innovation in our field. Because most of us don’t have programming skills, we often have to wait for others to do it for us. But this area is usually uninteresting to programmers.

Technical communication is an industry that has seen very little true product innovation in the past decade. The established vendors have maintained, essentially, the same product approach since EHelp: a predominantly single-author centric content editor with little emphasis on how users actually find and use the content created by the tool. Sure, there are lots of new features in the editors, but there has been no fundamental rethinking of documentation within the context of the modern Internet.

The documentation’s authority crisis and the technical communicator’s identity crisis will be the beginning of a new valuation for documentation from within the wider lens of a company’s overall content strategy and its quest to become and maintain thought leadership within an industry and customer segment. This shift will be dominated by multi-channel publishing of single-sourced, collaborative content that works to engage and bring users into communities influenced by the companies they orbit around.

Of course, like Gordon and Tom note, tools must evolve for this to happen. At LugIron we think about this every day as we march towards our first product release.

Technorati Tags: CommunityBuilding, CustomerSupport, Documentation, TechnicalWriter, TechnicalWriting

The ground is shifting in another major industry, old media, caused mostly by the rise of social media and the desire of users to find the news they want online, and there are some interesting parallels that should be considered.

In a recent conversation with Anne Gentle she shared with me some of her thoughts on the future of technical writers and the similarities that might be drawn with the downfall of old media. Quoting from her recent blog post on the topic:

Previously the best way to get your news was through journalism and your daily newspaper – but the publishing systems have changed and allowed for citizen journalism and news updates through various channels.

I naturally draw a parallel between citizen journalism and user-generated content. After all, in software, technical writers are like the journalist is – finding the relevant story for a particular audience, interviewing to get the facts, presenting in a fair, nonjudgemental manner, and writing to a deadline.

I think Anne is on to something here. Let’s consider this for a moment.

Journalists help define the debate within a community (most generally, our country). They source, investigate, and write about current news (things the community might find interesting), and the community members (citizens) take the debate and run with it.

Journalism helps create the seeds of modern social debate. Social media helps to highlight the fact that once that seed is planted the journalist, who used to be a position of power to control where the story goes, now becomes much more of a peer to the community–contributing additional thoughts and ideas but with no great advantage to distribute those ideas any more effectively than any other community member.

This is fundamental to the future of technical writers and documentation.

Helping People Learn from other People

Patty Seybold recently wrote an interesting post entitled “People Learn from People”. At the beginning of her post she writes:

Another pattern I noticed among our Visionaries was the various ways they connect people to people in the online world. As one participant said, “People don’t learn from information; they learn from people.”

Patty goes on to say that a sense of mission to help customers connect with other customers to share and learn from experiences is a critical criteria for companies to make effective use of social media to drive customer acquisition. In my own words, I would suggest that this all goes back to growing happy users.

The Modern Technical Writer

The enlightened technical writer understands the implications of the downfall of old media and how it relates to user education. They also understand that the ultimate goal of their work product is to build an engine that educates users using not only the words they write, but also the words and experiences of the community. To take Anne’s points and expand on them, here is the description that I believe begins to capture the technical writer of the future:

1. They plant the seeds of discussion by writing answers, not documentation.

2. They publish in a medium that brings users together, ultimately by building a learning community around their company’s content.

3. They understand the documentation is never done and iterate on it as needed by creating new content internally and accepting content from the community.

4. They value, but temper, the wisdom of the crowd to ensure the content is always correct.

5. They are part writer, part community manager, and part user experience advocate for their products.

Newspapers might die but journalism will live on. The value of journalism can never be questioned, but it is clear that the ground is shifting beneath the old media industry. Much the same can be said for technical writing. There will always be a need to help users understand how to use products, but there must be a realization that the “old documentation industry” will ultimately wither away entirely. Users are demanding answers in new ways, and writers need to adapt their means of providing that content. Ultimately, a new platform to help technical communicators write, publish, and manage the community debate is needed: social media, blogs, and wikis all provide the fundamental concepts and tools, but taking advantage of them is more easily said than done.

Let us know what you think!

Got an opinion on the future of the technical publishing industry? Leave a comment and let us know, we want to hear from you!

Technorati Tags: CommunityBuilding, Documentation, TechnicalWriter, TechnicalWriting, UserEngagement

Kevin’s blog is a treat to read and full of great tips and information. I’m a big believer that great customer service can hide many corporate and product flaws, and Kevin’s advice and suggestions are always insightful and helpful to read. Kevin defines a Point of Experience (POE) as every action taken by a company’s employees that result in a experience for a customer, and the sum total of those POEs is representative of the company’s reputation, image, and brand. POEs are also created as customers interact with a company’s website or its advertising campaign. A positive POE can result in a user who walks away with a positive image of the company. A negative POE can reduce or eliminate the value of previous positive POEs and turn a user’s perception of a company negative. Read Kevin’s blog and you’ll get a feel for where this is coming from.

So, is a company’s documentation a POE? Absolutely. In fact, I’d suggest that documentation is actually one of the largest culprits of negative Points of Experience’s out there. Take a look at this selection of tweets from this twitter search:

Not only does bad documentation create unhappy users, but if those users go to the point of sharing their negative documentation experience then the social web can cause a negative POE infection of sorts. The community can crown kings and also behead them, so as you write and publish documentation for your products you need to be asking yourself if you’re doing everything possible to turn your user’s interactions with documentation into positive Points of Experience.

This small sample of tweets is from people who’ve had positive documentation experiences. Take a look at the full search and ask yourself which one you’d like your product or company to be mentioned in. Kevin’s post concludes with this thought:

To keep our customers coming back, we need to create positive POE’s every time. To do this the company needs to have the value that says “I care” and actions that say “I serve”. If your company’s core values include caring and serving then the actions of people in your company will reflect this. And you’ll create points of experience that customers like.

Write and publish your documentation in a way that shows your users that you care about their experience, give them a positive documentation Point of Experience, and they will reward you with loyalty. Understand that your users ultimately want answers and give them a way to build a community without jumping through hoops. Use your documentation as a seed to grow happy users and I think you’ll find that the return on your documentation investment will increase dramatically.

Technorati Tags: Documentation, OnlineDocumentation, OnlineHelp, TechnicalWriter, TechnicalWriting, UserEngagement

A common advice for customer service requests is to improve the documentation, and this we have done for many years.

But I’ve noticed that we’ve reached a new level of this. Improving the docs increases the number of service requests.

Two reasons for this, based on feedback from customers seeking support:

1. Documentation is now so comprehensive that it is intimidating. People see a 1000 page manual and say “no thanks – I’ll just call customer support instead.”

2. Documentation has so much cool stuff described, that it makes people’s imagination stimulated and they start thinking of other, even more exotic stuff they want to do but can not figure out and start a service request for it.

Thus, the common solution to service requests – better documentation – actually causes more service requests, not fewer.

One has to ask then what really makes better documentation. It would appear in the case of this company, the solution of increased, monolithic documentation was not better. So what makes better documentation? When creating content are you writing to provide evidence of how things work or are you anticipating questions and proactively delivering answers?

Users Want Answers

Programmers are used to preaching that measuring lines of code is meaningless–it’s actually more valuable to have fewer lines of code assuming the functionality is not impaired. The size of documentation, however, is often times a measure of product robustness and capability. In the past I’ve even used documentation as a way to distract users from flaws within a product: “Look over here! See this big stack of manuals? Pay attention to this and forget about those bugs!” When training customers our documentation was always printed out and we always gave them multiple binders because we were trying to reinforce that our product was solid and trustworthy.

Unfortunately, as you might imagine, our documentation wasn’t written properly. Looking back on it we created (unintentionally) our documentation with size in mind, never answers. Our users ultimately wanted answers and they wanted them fast. Flipping through our documentation, however, made it impossible for them to achieve this so they often times turned to support for help.

When I hear people talk about the problem quoted above, I’m often times reminded of these experiences. A 1,000 page manual is useless if users can’t find what they need. Typically this is due to content not being written appropriately or if the navigation or search capabilities of the published form are lacking. Ultimately, if your user can’t find the solution in less than three steps I’d expect a support call or email, or at the very minimum a frustrated user asking for help on a public forum.

What Are You Gonna Do About it?

Every customer support interaction is an opportunity to improve documentation.

I’ll say it again. Every customer support interaction is an opportunity to improve documentation.

Users always have questions that aren’t effectively covered in the documentation. Like taxes, this fact of life will always be with us and it is actually a good thing because it is representative of customer use. The more important question is what do you do with those questions after they’ve been solved? Do you use that experience as a way to head off similar questions from other users? Ultimately, users would prefer to not talk to you about their problems if they can easily figure out the solution themselves. How easy you make it is your choice, but to do it effectively you should consider how to continuously improve your documentation with “evergreen” content.

Think of your documentation as a tree. As it is published it’s like new spring growth. The leaves are green and the tree is happy. Over time your documentation tree needs to grow new branches and leaves because the old content becomes stale or doesn’t adequately address the needs of your users (would your users, in this analogy, be the birds and squirrels?). You need to prune the tree, fertilize and water it. Making it easy for the community to help in this process is critical, especially since most writing teams are understaffed and outgunned. Using the right tools and empowering the support teams and user communities to help you do this is both necessary and advantageous as it ultimately helps your company to create power users–engaged users who advocate for the success of your products.

When an author writes good documentation they ask themselves, “How will the user actually use this documentation to find the answers they need?” If they get it right and if the content is sufficient then there would be few customer support interactions. But when a customer is upset enough to call or email support, then you have a real-world feedback on how well your documentation answers that key question. This is extremely valuable information; indeed, UI developers pay good money to have user studies on their software before it’s released. Don’t squander this information!

Still don’t believe me? Consider this: the process of writing good documentation is much like making a good website. You don’t want to focus on throwing out information; you want to focus on how people will use it. Web developers have understood this for some time, just check out this chapter from the Steve Krug’s book, “Don’t Make Me Think“. There is an interesting synchronicity between product documentation and web content to consider, which only grows as documentation continues it’s migration to the web.

Let us know what you think!

We’d love to hear your experiences with documentation especially as they relate to how you design, author, and deliver content so your users can effectively find the answers they need.

Technorati Tags: Documentation, DocumentationSucks, OnlineDocumentation, OnlineHelp, TechnicalWriter, TechnicalWriting

The presentation, which appears to be a short summary of an upcoming Forrester research report titled “The ROI Of Online Customer Service Communities”, states boldly at the beginning:

The #1 customer service initiative for 2009 should be social media

I have to say that Forrester and Dr. Petouhoff definitely seem to get it. She is a long time and well respected analyst in the customer service and customer relationships and I’m encouraged that this report is the beginning of a broader move by large companies towards changing how they interact and engage with customers. Near the end the presentation states that the payback of these efforts, as measured by the Forrester methodology and assumptions, can be less than 12 months.

If that metric holds to be true then companies can hopefully stop worrying about the payback of social media and instead focus internally on the changes they will need to make in their culture and value system to effective use social media to engage with customers. After all, before a company can realize an ROI on their investment they must learn to make effective use of the new medium, which I think will be significantly harder for the majority of organizations out there.

Technorati Tags: CustomerEngagement, CustomerSupport, SocialCustomers, SocialMedia, UserEngagement

Take, for example, Daniel Worthington’s experience with the HP documentation and support site described in his eloquently titled blog post, HP Printer Documentation Sucks. If you weren’t convinced after seeing the title then reading the first paragraph will reassure you that Daniel’s experience was bad:

I recently had to turn to HP’s online help documentation while setting up a networked color inkjet printer for a Faculty member at work. I always dread visiting HP’s website, but on this particular day my experience was unusually heinous.

Daniel describes a frustrating experience trying to find the help he needed. Recall from my previous post, Does Your Documentation Suck?, that there are three critical factors needed for good documentation:

1. Quality and Completeness of Content
2. Search, Browse, and Read Experience
3. Interactions and Content Freshness

Daniel’s experience illustrates that if you lack any of these then you risk frustrating your user at a time that they most need to have a positive experience. He found inaccurate procedures, a frustrating search experience, and a feedback process that left him feeling ignored.

Remember, users reading documentation are usually looking for help or looking to be influenced. At this time, they are ripe for you as a company to turn them into an engaged user with something positive to say about your product or company. Unfortunately, Daniel’s experience is all too common and the documentation or support process fails to help them solve their problem, or at the very minimum creates significant heart ache.

To add insult to injury Daniel goes on to try to help improve the experience of users that may follow him.

Well, right underneath the very usefull Stuffit Expander disclaimer is a “content feedback” form where I can vent my frustration and hopefully someone at HP will take a look and write up some better documentation. So I filled out the form. I tried to be constructive. I pointed out that “upgrade install” didn’t make much sense and that removing all the printers wasn’t the most user friendly approach.

“This is good,” I’m thinking. “I’m making a difference.” I clicked submit. Oops, page not found. I guess I should have read the very bottom of the page before I clicked submit:

Please note this form is for feedback only, so you will not 
receive a response.

The sad thing is, this little document is just the tip of the iceburg. HP: your printer driver documenation for Mac OS X Sucks.

He actually tried to leave feedback only to be brushed aside by a poorly designed web site that didn’t work.

Companies of the world: your documentation, and more broadly your support experience, is a unique opportunity for you to help a customer out of a jam and in doing so potentially turn them into an engaged, happy, contributing user within your community. If you’re trying to do this, and by all means it appears that HP was at least interested in hearing what their users have to say, you must follow through. Asking for feedback and then failing to hear it (whether intentionally or through a failure to receive it) is a sure way to create a bad experience and grumpy users both of which have a negative impact on your business way beyond the initial interaction, as is illustrated by Daniel’s blog post.

Let us know what you think!

Do you have a good story about when documentation has helped or hurt your experience with a company? Let us know, we want to hear from you!

Technorati Tags: DocumentationSucks, OnlineDocumentation, OnlineHelp, TechnicalWriter, TechnicalWriting