Visit InfoSourcing Home Page

Information Sourcing
On Demand for Small and Medium Business.

Home » Services » Our Approach » Persona Based Documentation
Persona based documentation

1. Define your audience
2. Prioritize technical writing tasks
3. Task based approach
4. Proof reading by audience
5. End user survey

1. Define your audience

One of the first steps in documentation is to determine the audience. Whether it is technical or functional or simple conceptual manuals, one has to understand who the end users would be for what we write, there are multiple kinds of people who may be using the product: new users, expert users, occasional users, daily users, and IT administrators, for example. If you are using a product like Microsoft Internet Explorer your users could be spread across different departments in the organization. Try writing your manuals would be burning your fingers without understanding the end users user skills and this is where defining the audience comes into picture.

In the field of Product Management we call those as "Personas", the personas are designed by the product managers who understand monitor or discuss more often with their end users during requirements gathering of the Inception stage and this are the end users who will be reading your documentation. Understanding the personas will help you understand vital characteristics about your readership, including their technical expertise and the environment in which they will use the product.

If your product is big such as enterprise software where it spread breadth and height then you might consider having the persona set large and varied, you may discover that some users have needs so distinct that they require their own section of the document, such as an advanced configuration chapter targeted at an IT administrator. If so, you'll know that you can write that section for a more technically sophisticated user.

2. Prioritize technical writing tasks

If your building a new product documentation is always scheduled at the end of development life cycle, there is not much your technical writers can do apart from putting a piece of English literature on paper.

Your documentation team should be involved from day ONE, it would come much before development of your product and it starts by referring to Personas allowing documentation teams to be prepared with framework of design and get a feel of its end users, rather than the conventional way of documenting at the end of the development life cycle leading to chaos and not able to do justice to its product or to its customers.

Schedule slips early in the product development cycle can mean that you won't have adequate time to document the interface in as much detail as you might like. How do you figure out what to spend time on during the triage writing process?

Solid personas and design documentation can help you prioritize your writing tasks. Figure out what's most important to the persona, based on their defined goals and tasks, and document those aspects of the interface first.

3. Task based approach

Most of the documentation materials describe the user what to do keeping a generic user in mind and forgets the personas level approach. For example if you had to document for Microsoft Word create new document, your documentation would approach it straight forward with Click "File" and Choose New document and the user is left out on the white page. If the user is a beginner/student understanding the persona would help you to document differently as indicated below:

a) Open Microsoft Word, Click File and choose create document b) Choose template from pre-defined templates for resume writing, normal document, cover letter etc c) Choose a font family and presentation appearance d) Specify header and footer content e) Indicate the user to preview the document before printing

By describing the steps would allow any user to not only create new document but also takes them one step further in making them feel easy, which makes reading documentation fun and helps to explore more about the product.

4. Proof reading by audience

Ush Ush, you are product is ready for beta release and it is the right time to share your documentation work to technical/functional audiences and let them test run your product and refer to documentation, that gets shipped during beta cycle as "Draft", this way your users will see how well the document flow is documented, it will allow them to understand the system better with regards to user interfaces.

People refer to such audience as Customer Advisory board (CAB) or focus group or simply beta customers, who would not only be your beta testers in real environment but also get their hands on to documentation and thus help you to fine tune in certain areas for the final releases, allow to catch any grammatical mistakes or improper installation of files as they get integrated into the product or soft keys etc.

5. End user survey

We don't think there is a need for a survey, don't we? If you visit your customers and see how they are using your product manuals/documentation you would be surprised to see those documents lie in a corner piled up biting dust, why?

If there is no defined approach in your documentation as explained above you would hit the dust, it is necessary to understand your end-users and document, without which we would be indirecting affecting increased support and implementation calls coz of poor documentation.

To have a health system it is always recommended to conduct a yearly survey or every major release of the product, collecting such effective data will allow documentation department to cater to user needs and be able to adapt to newer technologies of documentation, old saying "either you pay now or pay later".

For any product based company it is essential to understand this approach and maximize the investments by involving documentation ahead in the cycle.
Enterprise/ERP Software
Web Design and Development
Search Engine Optimization
Business Process Outsourcing
Documentation Outsourcing
  » Why choose Info-sourcing
Expertise in optimizing eCommerce sites
Specialist in small and medium business
10 yrs of web consulting experience
» Small & Medium Business ERP Software  Comparison
» Google Checkout online payment competitor for PayPal
» Shopping Price engines demystified
» Evolving User Interface