|
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.
|
for Small and Medium Business.
