Introduction

To quote the wiki definition of project management:

“ Project management is the discipline of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria”.

No great product can be created and launched with ease without proper estimation and planning. So is the case even with documentation or user assistance, which goes a long way in enhancing the experience of the user with the product. A great deal of planning is required to run, execute, and complete the product user assistance project.

The article focuses on the considerations to be kept in mind while creating user assistance or documentation for any product.

The Nitty-Gritty of User Assistance Projects

The User Assistance (UA) today is not confined to just writing but calls for better project management skills to run as an independent and significant department within the product life cycle.

Here are some of the key questions that are worth considering in any documentation project:

• Who will create and what? (Authoring and deliverables)
• Which are the channels to publish? (Delivery Channels)
• For whom will we write? (Audience)
• How many of us will write? (Team and Task)
• How much will we write? (Content Volume)
• Into how many languages we are going to translate the content? (Localization)
• What would be the cost of translation? (cost)
• How much time is required to develop content and publish? (Timeline)
• What tools are we going to use? (Tools)
• To what extent we can use single source and reuse strategy in addition to other content strategies such as profiling, versioning, linking etc.
• What is the scope of innovation for our content management?
• How are we going to collect the user feedback later?

Just imagine if we were to start writing at once without considering any of these? Getting started with writing mechanically without any consideration for any of these is unproductive.

Authors and Deliverables

Different companies have different ways of managing documentation projects. Some companies might as well efficiently track these with an excel. While few other companies might have dedicated tools for project management. Further, it is also possible to carry out project management in the DITA based content management systems.

Every project – technical or non-technical – requires human resources, who are hired based on the required skills for the docu project. Lot of time goes into finalizing such candidates to form a team. Thus, there is a need to plan the budget and time required to form a team. Sometimes a project might require a single resource with good knowledge to set up the docu project from the ground up while few other docu projects might require more writers to support the docu project.

Writing requirements might also differ from project to project. A docu project supporting an on-premise version of the product might require a different set of deliverables and delivery cycles. On-premise release might require writers to create and publish content quarterly or so. For a cloud version of the product, deliverables could differ. For example, an Installation guide may not be required for a cloud based product, which is available to customers remotely. But the challenge of keeping the customers engaged through appealing docu is always there because the customers have the choice of subscribing to a product for a short period and can leave it if the user experience is bad.

So, plan these aspects in advance prior to writing.

Delivery Channels

Where do we publish the content that is created?

• Documents on the company help portal
• Do we provide help in the application?
• Is there an appropriate tool that supports integration of such help content from Content Management System to the software product? Consider the options and the feasibility?
• Do we also use social media to talk about our product and its cool features?
• Do we provide infographics?
• Do we offer videos on features and tasks?
• Do we have enough infrastructure and expertize to create such diverse deliverables in addition to documentation?

Address these concerns prior to setting up the docu project.

Audience

Who will be reading what we write – is it a mixed group of novices and experts? Or is it only the business users? Are there even technical audience and how do we balance content for these different set of audiences? What is their background – language should be simple or moderate. Consider the cultural aspects while using certain terms in UI or in docu – a single usage might have different connotations in different cultural contexts. Need to be aware of that as well. Do they need detailed information? Or they just need assistance with complex tasks?

Team and Task

A thought on how many writers will collaborate for the project and on what aspects of the product helps. Who has skills to create which deliverables? If there are more writers in a project, some might have a better understanding of what to provide for a business user while some might have a better skill to provide accurate info for a technical user. Hence give a thought and plan to match the skills to requirements in advance.

Content Volume, Localization, Cost, and Timeline

Assess the volume of content for each deliverable because if there is localization for the project, it helps. Care can be taken to provide concise information in localized deliverables without compromising completeness and clarity.

How much of time is required to create, review, and publish all deliverables? Would there be a mismatch of estimates for timelines? Such an estimate helps to track the current situation and communicate to the stakeholders with credibility. This also ensures accountability at individual level as well because writers align and provide an estimate for themselves (based on product development timelines) and  it is not made by others for them. What are the issues that are likely to come up after the content is produced? How much of time should be kept as a buffer to address such unexpected issues during publication.

At the same time, the current estimate might help in assessing future efforts required for a similar project.

Content Management and Other Tools

What tools are we going to use for creating content and another media for the project?

Are we going to stick to age old tools? Are we going to invest on advanced tools for a better user experience? Do we opt for DITA based tools? Is it worth investing in an advanced writing tool?

What is the feedback about the tool in the technical writing circles?

What tool to use for illustrations, infographics, and videos? Do we need a professional graphics specialist? Are there open source tools that we can use? Do we need to buy an advanced tool for creating graphics and illustration?

Is there appropriate audio support for the created videos? Should we have a dedicated blog page for our product wherein writers can contribute?

All these considerations should be openly discussed prior to content development. This helps you plan and deliver the project better.

Content Strategies

How are we going to handle single sourcing and reuse in our docu project? In other words, do we use the same source to create multiple outputs such as PDF and HTML. Do we reuse the same source in subsequent versions? If yes, how do we accommodate the new content with the old content.

What are our strategies to clean up the content periodically based on the changes in style aspects?

Trends and Innovation

What are the trends in user assistance outside? How many of these are suitable to try in our project? What are the trends in customer expectations in a similar domain? What are the expectations in terms of user experience? For example, can we provide fuzzy search in our docu help page? What measures would aid our help page show up in search engines?

What other writers at SAP are doing that is innovative? How can we reuse and accelerate current developments to incorporate their innovations into our solution or offering? What common approaches we can reuse? How can we better integrate for a seamless  customer experience.

User Feedback

Last but not the least is how do we improve product experience in future? This is possible when we are open to feedback from the customer. How do we collect such feedback? Should the users be allowed to share feedback on each pages of our deliverables in the product documentation portal? How do we respond to them? Is there an option to subscribe to customer feedback from the portal? Out of such comments, how do we segregate product related feedback and docu related feedback and the ways to address them efficiently.

Conclusion

These are only few generic aspects. There could be many more factors specific to your product and project. Some of these generic considerations listed above determine the success of any product through a well-planned user assistance project. Hence planning and managing these aspects in a professional manner benefits the product, people using it, people creating the product etc. Not just that, but uncertainties, frustrations, loss, and imperfections can be ruled out or minimized. On the other hand, efficiency, accuracy, and usability is ensured.