Search results

The Enterprise Help Authoring Problem

by Tom Johnson on Feb 16, 2011
categories: technical-writing

In my organization, we're in the middle of trying to come up with a solution to address enterprise-wide help authoring. Currently we have a lot of pocket groups of writers working in silos. We think an enterprise-wide solution that unifies help authoring would be a step forward.

Siloed Publishing versus a Unified Help Strategy
Siloed help authoring (left) versus a unified help authoring strategy (right). How do you make this shift?

I would love if it someone could recommend a solution. Here are our requirements.

Enable consistent-looking, attractive deliverables. Currently help across the enterprise takes all shapes and formats, since most authors work in silos using the tools they choose. Help produced by the different groups looks as different as help produced by separate companies. We want to create a consistent --and attractive -- look and feel to help materials produced by our organization.

Enable non-technical people to author. Sometimes non-technical writers, such as domain experts in business departments or project managers, need to author content. We need to a process that allows them to author comfortably without getting hung up with complicated authoring methods or tools. A simple authoring solution would also increase the likelihood that writers from the various silos embrace our solution.

Allow community members to collaborate. We have a wide number of community members who also need to collaborate on content as well. Community members are outside the firewall and may have only rudimentary technical skills. These community members volunteer their time and talent to work on documentation and other content projects. We need them to be able to author content, too.

Share and re-use content. We need to share and re-use the content that we create. We may be mixing and matching different topics in different outputs, and also working collaboratively on the same project. We want to leverage content re-use where necessary to allow us to compile different deliverables that draw upon the same content base, such as online help and printed guides and training guides.

Translate content. Much of the content we create needs to be translated. Translation department requires the content be in Word, XML, or UTF-8. Another translation group uses LingoTek.

Allow users to easily find the content. In addition to improving the authoring process, users also need to easily find the content. Some departments have thousands of pages of content. We need a way for users to search through that content to find the right information quickly.

Permission levels for certain kinds of content. Some content is permission-based, so only users in certain roles should be able to access it. All users with these permission level requirements have their role identified through a central identity access management system.

We're open to any solution at this point, and cost is not an overriding factor in the solution. We do have a thorough SharePoint integration internally as well as a robust Mark Logic database. Externally some content is on Mediawiki. Because of the size of the organization, we do have a lot of in-house experts. What would you implement for this situation?

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.