Post History

Source: https://writers.stackexchange.com/a/17016
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

In many ways you approach this the same way you would approach any other new project:

- Review any available high-level descriptions (like functional specifications) and user stories: what is this thing and how are people meant to use it?

- Identify your key contact (if you don't have one, ask your manager how to get one) and schedule an overview discussion. This is a "give Ashvita the lay of the land" discussion, not a "tell Ashvita all the gory details" discussion.

- Sit down with your contact and the software and get some hands-on exposure. Don't try to cover everything; ask the expert to point out the _most important_ and _most common_ paths through the tool.

- Start to compile questions (which will surely arise as you work with the product).

Now in addition, this product has been around for years and people have been using it, even without documentation. Either everything is completely obvious (in which case they probably wouldn't have asked you to document it) or there's a lot of "oral tradition", maybe even informal notes, wiki pages, and so on. You want to tap into that.

You should ask your key contact for pointers to any such artifacts and, also, who the main in-house users are. (They might be your own QA department, if you don't have people in-house relying on the product.) Gather the information you can.

That's all about the _research_ part. To _organize_ everything you need to have some sense of who your users are and how they'll use the product. The same techniques that you use for other technical-writing tasks apply here. A full treatment of user-needs analysis and organizing content would be too much for one Stack Exchange answer, but feel free to ask narrower followup questions.

Original score: 2