Contribute in GitHub:
Open doc issue|Edit online
Technical Content Strategy
Content Standards
Introduction
Content strategy is the discipline responsible for satisfying business requirements through content creation and distribution. Of course, there are a lot of people out there writing, designing, creating content. Content strategy implies that someone is stepping back and asking, “What should we create, and why?”
Overview
Technical content @ IBM means UI content, Product doc, support content, and training content. You may also find yourself in the world of community, developer, social media, or others. However, for the purpose of this guidance we focus on just those four content areas.
The content strategy at IBM first and foremost focuses on user needs. As in all disciplines at IBM, Design Thinking principals are central to any content design and creation.
When you embark on the effort to determine the content strategy for your BU, it is important that you focus on these 7 content strategy principals:
(1) Select technical content types
- What content types do your users need to be successful?
- What type of content: UI, Product doc, Support, Training, other?
(2) Identify where your users need the content
When is the content needed?
- UI
- Product doc
- Support
- Training
- Community
- Developer
- Social Media
- other?
(3) Plan for delivery of content
- Align the content users need with the development delivery cycle?
- What content is priority? What content can wait and be delivered later?
- What content is needed when?
- Where is the content going to be delivered?
- What pain points do you want to proactively account for?
- What training is needed and when will it be released?
(4) Monitor feedback loops
- Identify how and where you will get user feedback for the content. Plan for consistent monitoring and folding in of changes per that feedback.
(5) Define your metrics of success
- Monitor your content usage through metrics and setup a regular cadence to review and plan changes per the metrics you recieve.
(6) Define your standards of quality
- Work with your peers in content to define what "done" is and what quality content means for your product set.
(7) Track maintenance and updates
- Whether ties to a development release or updates that stem from feeback or metrics, you must allow time and effort to make updates to the content you have already released. Clearly define for your teams as well as the larger product team how you will handle this outside of the release scope of content updates.