When I started at my current company, there wasn’t an intake request form for documentation requests. Any ad-hoc requests that came from the Product team, we would discuss in a weekly meeting. Other requests, such as doc site maintenance or updates from the Support team, were sent as an email that created a Jira ticket. When I began working with a CI/CD Engineering team, I quickly found out that winging it didn’t work. I had no system for assigning story points, didn’t know what tasks I could get done in a two-week sprint, and spent a ton of time asking the same questions over and over.

I created this request form as a way to standardize the general information needed for feature documentation requests. It makes my job easier because I know I’m getting the initial information I need. I also found that it filtered out requests that stakeholders couldn’t define. Sometimes, the only information I had about a request amounted to a Slack message that said something like, "Can you document X feature?" This may not be an issue if you can test the feature, but if it won’t be implemented until the end of the sprint, you don’t have much to go off of. If you find you’re frequently getting doc requests with little information, using something like the form below may help establish that you need information up-front before you can come back with an answer.

Note: As the tech writer, I don’t expect stakeholders to answer everything in this form for all requests. I work with them to fill it out, adapting the form to the needs of the specific request. I also take ownership of some items, such as what type of document is needed, where on the doc site it will be located, and whether peripheral articles need to be updated.

This form references software I use at my job, such as Jira and Figma. Be sure to update that if it’s not applicable to you.

Documentation Request Form

REQUESTOR DETAILS

Developer and/or SME(s):

Project lead/Architect:

Product owner:

DOCUMENTATION DETAILS

Document type:

Concept, how-to/task, reference, getting started, troubleshooting, or release notes?

Link to draft(s) in progress:

Article(s) to update:

<Link(s) to doc site articles that are affected by this change>.

Proposed location of new article:

SOFTWARE SPECIFICATION

Link to Jira issue(s):

Description of new feature or update:

What does the feature do? How will the user use it? Why should the user care about it?

User story:

As a <type of user>, I want to <perform a task> so that I can <achieve a goal>.

Acceptance criteria (if not in Jira):

Given <a precondition>

When <some action is taken>

Then <a set of observable outcomes should occur>.

Figma design (if a new feature):

Happy path:

What steps does the user take to perform a task?

UI changes:

What areas or screens of the product have changed?

Edge cases

Are there any known issues that occur at an extreme operating parameter?

Other notes:

Here’s a PDF version.

Of course, the pitfall with a one-size-fits-all form like this is that requests come in all sizes. I’ve had to adapt this for different teams and products. Even then, not all features within the same product behave similarly enough that it makes sense to apply a generic template.

This form is a starting point when you’re asked to document something you’ve never seen (and possibly won’t see for a while). If you can get Product, Engineering, or QA to spend a few minutes answering some standard questions about the new feature or update, you’ll be in a much better position to start writing.