---
title: "A tip for doc reviews – bring a list of questions"
date: 2020-07-24
description: "How to have a bad doc review Better doc reviews The list of questions Listen here: <audio controls="
canonical_url: https://idratherbewriting.com/blog/tip-for-doc-reviews-bring-list-of-questions/index.html
---

> For AI agents: a documentation index is available at https://idratherbewriting.com/llms.txt. Markdown versions of all pages are available by appending .md to any page URL.

# A tip for doc reviews – bring a list of questions

> Although doc reviews are a central part of the tech writing process, it's often a challenge to get teams to review docs. One tip is to bring a list of questions to the doc review. This provides more structure and focus to the review meeting.

**Listen here:**

[Audio](https://dts.podtrac.com/redirect.mp3/s3.us-west-1.wasabisys.com/idbwmedia.com/podcasts/doc_review_list_of_questions.mp3)

[![](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/apple_podcasts.png)](https://itunes.apple.com/us/podcast/id-rather-be-writing-podcast/id277365275) [![](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/watchonyoutubeblack.png)](https://www.youtube.com/@idratherbewriting) [![](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/spotify.png)](https://open.spotify.com/show/4HeOZfPGMMfViOhVS40QBD)

[Video: Video](https://www.youtube.com/embed/Mi1bFiWiesA)

## How to have a bad doc review

If you want to have a *bad doc review experience*, try doing any of the following:

- Send out an email blast to an entire group asking them to review the docs (group emails are easy to ignore)
- Send out more than 5 pages of documentation to review (reviewing too many docs at once can be overwhelming)
- Show up at a doc review meeting without a specific agenda or list of questions to cover (reviewers might shrug their shoulders and say everything looks fine)

## Better doc reviews

I find that doc reviews go much better if I do the following:

- Ask *specific people* to review the docs (usually 2-3 people)
- Send the reviewers a short amount of content to review (something they can read in 20 minutes)
- Allow time in the meeting for them to read the content (if schedules allow for it)
- Provide a list of questions you want to ask

## The list of questions

This last point is one I’d like to expand on — the list of questions. I find this is the absolute best technique for successful doc reviews. People don’t often know what to focus on when reviewing documentation. Their feedback often jumps all over the place, focuses on trivial aspects, or other times transitions into product design issues instead.

However, usually after writing docs, we have specific areas that we’re unsure about, about which we have questions, or about which we feel might need more details. I gather up all my questions and list them out in a document so that people can see and review the questions. I often share this list of questions with reviewers ahead of time and use it to structure part of the doc review meeting. I start off by asking for their feedback about any part of the documentation, and when they run out of questions and comments, I start in on my list.

People love seeing questions in a list like this. It focuses the meeting, gives more structure, and provides reviewers with a starting point for their comments.
