| Company: | Numara Software |
| Location: | Tampa, Florida, USA |
| Purpose: | Engaging users in document content strategy |
The technical writing team at Numara Software was looking for a way to gather feedback from customers on their product documentation. Neither of the two existing platforms they used to publish online help provided any facility for customers to provide comments or feedback on the quality, accuracy, or usefulness of the documentation.
Numara’s own software products did include some feedback and survey capabilities, but they were not linked directly to the documentation. The feedback loop was handled by the support department, and the documentation team had no direct contact with customers. The few comments they did receive via this method were vague and difficult to link with specific documentation subjects.
The team undertook a study of feedback and customer collaboration practices in order to develop a solution that would not only have a feedback facility, but would also provide a mechanism for customers to contribute directly to the documentation itself.
The existing documentation was structured to answer basic “how do I?” questions by providing detailed information on the product itself, and the support knowledge base was structured for trouble-shooting. However, there was no process for capturing specific customer use cases that could answer “how do I get the software to do this?” questions.
This sort of information is best supplied by the user community itself, since they have the most experience using the software in real-world situations. The user community had developed its own mechanisms for answering, and sharing, these sorts of questions using online forums, user group mailing lists, etc., but there was no systematic way of capturing this information and incorporating it back into the documentation.
The vision for the project was to provide a company and customer driven knowledge base, with the aim of making users self-sufficient.
Additional specific goals included the following:
The project team conducted focus groups and surveyed customers on potential feedback and collaboration solutions. They found that 100% of all customers surveyed expressed a desire to contribute using a wiki. In particular, customers wanted a structured wiki with links to support and user forums, all monitored by the company.
The project team thought that using a wiki as a knowledge-base portal that included other areas of company-created content would be a good way to maintain control of the brand. Numara did not want customers searching the web for answers when a Numara wiki could give customers the most up-to-date information possible.
They felt that giving customers an organized site on which to share information would lead to the the generation of examples, best practices, lessons learned, case studies, and testimonials, and would also encourage the emergence of community leaders.
The project team wrote a product requirements document to help detail objectives, scope, constraints, resources, milestones, and stakeholders. The WikiMatrix Features List was used to develop a list of business and functional requirements, including the following:
After researching and testing several wikis, the project team settled on the Confluence wiki as best meeting their needs. The wiki was populated with a combination of legacy information imported from Microsoft Word source documents and pages written from scratch – the latter so the project leads could become familiar with the process and with the Confluence mark-up, macros, and plug-ins.
After a month of internal testing and trials, a pilot project, called the “Numara FootPrints User Community,” was rolled out to customers who had participated in the focus groups. The rollout was accompanied by a newsletter promoting “The 10 Things You Can Do” as a member of the user community:
As part of the pilot the team also developed a set of Contributor Guidelines, a full Disclaimer, and a User Agreement. A self-guided tutorial was also provided, and a couple of live online training sessions were offered.
The pilot project ran from April through August, 2010, during which time the team monitored the wiki for functionality, usage, feedback, and usability.
Some of the early keys to success included the following:
Overall, the project team found that just by using the wiki instead of working in independent “content silos” and separate help authoring systems, they improved team collaboration, communication, and productivity. They also noticed a reduction in the need to send email and spend time on the telephone. All are now literally “working off the same page.”