"This Installation Guide looks interesting....would make a good travel companion." "What a great User's Manual, a must read for all administrators" If you are reading this, you are probably thinking that I am crazy and almost going to close this window. Not yet :) Just give me a couple of more minutes here. I am with you as well! No one wants to read a technical document for pleasure. The one and only purpose you, me or anyone would even care to click on that Help icon on the screen or open a PDF, is to accomplish a task that we need some help with. A task that is not really intuitive or complex enough that needs some additional help to complete.
So how do we plan and write our documentation to cater to their needs? Our engineering teams are distributed globally. If we are lucky we get some ideas about the product in development. One fine day someone gives us a functional spec and may be a piece of hardware or a software to try out and write. And we write. We definitely try to use the product, think about how it works, imagine a real life situation and write what we understand. We do make sure that its technically accurate.
But how does that apply to the user? Is the user able to get what they want from a document that is technically accurate but does not give them the support they want? We don't want someone to read a document and call customer support to figure out what's written in the document.
I think asking the following five questions would enable us to focus on the user who will actually need some help at some point when they in the process of using this product:
Who is our audience? Does this product cater to beginner level users or advanced administrators? Having an answer to the who will help us to plan the document.
What do they know about this product? Are we writing for a product that is already available? is this a brand new technology? This helps us to plan how much conceptual information we want to provide.
Why will they need this document? An answer to this question enables us to plan the documents we need to write. Are they looking install, configure or upgrade something? if all these are intuitive, are they looking to use this product?
When would they need this document? Will they need it as they use this product? Before or after installing? the Why and When might look similar, but this when helps you with Information Architecture. You can decide if you want to provide an Online Help system or a Quick Start guide based on the answer to this When.
How will you know the users and product? Are you only talking to the developers working in their feature silos? Working with Product Management or Marketing? Are you able to meet with the actual users to understand their needs? Or do you have access to the teams within your organization that directly work with the users/customers?
Tools and Processes may vary, they way we deliver information may vary, but if we can find the right answers to these five questions, we will definitely be able to provide user focused document that will actually help the customers.
So how do we plan and write our documentation to cater to their needs? Our engineering teams are distributed globally. If we are lucky we get some ideas about the product in development. One fine day someone gives us a functional spec and may be a piece of hardware or a software to try out and write. And we write. We definitely try to use the product, think about how it works, imagine a real life situation and write what we understand. We do make sure that its technically accurate.
But how does that apply to the user? Is the user able to get what they want from a document that is technically accurate but does not give them the support they want? We don't want someone to read a document and call customer support to figure out what's written in the document.
I think asking the following five questions would enable us to focus on the user who will actually need some help at some point when they in the process of using this product:
Who is our audience? Does this product cater to beginner level users or advanced administrators? Having an answer to the who will help us to plan the document.
What do they know about this product? Are we writing for a product that is already available? is this a brand new technology? This helps us to plan how much conceptual information we want to provide.
Why will they need this document? An answer to this question enables us to plan the documents we need to write. Are they looking install, configure or upgrade something? if all these are intuitive, are they looking to use this product?
When would they need this document? Will they need it as they use this product? Before or after installing? the Why and When might look similar, but this when helps you with Information Architecture. You can decide if you want to provide an Online Help system or a Quick Start guide based on the answer to this When.
How will you know the users and product? Are you only talking to the developers working in their feature silos? Working with Product Management or Marketing? Are you able to meet with the actual users to understand their needs? Or do you have access to the teams within your organization that directly work with the users/customers?
Tools and Processes may vary, they way we deliver information may vary, but if we can find the right answers to these five questions, we will definitely be able to provide user focused document that will actually help the customers.
