Hiya! Welcome to this session of the “How to Make Guides” project where I’m creating a guide to help users create their own instruction manuals. In the previous session, I drafted the bulk of the production phase, specifically sections about drafting the guide and reviewing and testing it internally. In this session, I’ll tackle the external review process as well as the Beta Test.
To start this session, I’m going to copy/paste the review section from Cryptiquest’s current project management guidelines and start editing:
Phase 4: Peer Reviewing Your Guide
By the end of this phase, you will have gathered feedback from various sources to refine your work into a semi-final draft.
Step 1: Research your target audience and how to reach them.
Now that a draft has been created, internally reviewed, and alpha tested; it’s a good time to review your target audience and research outreach. Review the target audience section of your project document that you created in Phase 1. (If you didn’t follow that step, it’s pretty important to do so now.)
Take a session to explore methods for reaching your target audience. Are there groups that they are a part of that you can easily address? Or perhaps there are online forums where some users exist? Once you discover where your target audience might be reached, the next thing to consider is the best way to approach them. Professional sales pitches might be better for some groups while genuine, down-to-earth “I’m just a fellow creator looking for help” requests might be better for others.
Even though you might not be reaching out to the target audience until a few steps later, performing the need-analysis now is crucial since reviewers often wonder how they are supposed to perceive the material. They will want to know what kind of audience they are reading for and what that audience is supposed to take away. This information will help them advise you more effectively.
Step 2: Prepare the drafted work for external review.
Prepare the drafts in the medium in which you are going to share them with the reviewers. Are you going to print out the material and mail/hand it to them? Are you going to place it into a cloud service and email it or message them on a social media platform? However you plan on presenting it to them, prepare it and perform another review (silent-read through). Sometimes seeing it in the new format reveals typos you missed the first time.
Step 3: Send the drafted work for confidant review.
The first draft for an external audience is sent to one or two confidants. Ask them if they would be willing to critique your work but be respectful of their time. When asking for their help, provide them with the amount of reading involved before they commit. Only upon their acceptance of the critique should you provide them with the work (to avoid the risk of coming off as presumptuous).
Step 4: Edit the work then send out for second-draft review.
Ensure you thank your reviewers upon their review. It is important to note that you do not need to implement every (or any) change that they suggest. Often times, reviewers are good at identifying problems but their solutions are less helpful (since they cannot fully understand the intent of your work as well as you). Carefully consider the suggestions and make changes that help meet your project’s needs.
Once you make the changes, send the latest draft to the “second-draft” group. Reach out to the target audience using the methods you identified in Step 1 (if possible). This group of people should consist of 3 – 5 people who are different than the confidants. It’s good to have a larger pool to choose from as this group might not be as regularly committed to the task or as knowledgeable of your cause. Despite this, their critiques are just as valuable and their efforts should be equally appreciated. Again, be respectful of them and their time: ask them if they are willing to critique your work and wait for their affirmation before sending them the material.
If you do not have a group of “second-draft” reviewers at-the-ready, consider joining an online forum or finding a local group in a newspaper or library.
As you get feedback, make edits to the draft following the same principles stated in the first paragraph of this step.
I think that’s pretty good. I’ll now move on to the beta test phase though looking through my notes, I was originally thinking that implementation would happen before beta test?
Oh I think I see why – in order to have other people test the guide, they must have a functional version of it and the “review copy” might not be usable as-is. However, if we take the extreme case and assume the finished guide is supposed to be a full color print on glossy paper with illustrations, etc. then that could be an expensive endeavor for something that has yet to be tested by anyone other than the creator.
So, perhaps what is needed is an intermediary step – a draft version of the guide but with the necessary illustrations so users can test. Perhaps we’ll refer to this as the prototype? Yes. I like that.
Let’s take a stab at drafting this phase…
Phase 5: Prototype Testing
By the end of this phase you will have generated at least one prototype of your guide and performed at least three different tests.
Step 1: Analyze Your Prototype
Once the copy for your guide is peer-reviewed, catalog what parts are missing (e.g. illustrations, etc.). If the missing parts are necessary for users to understand the instructions then assess how much work is needed to create those parts.
For elements that might require costs or professional design (e.g. an illustrated example, etc.), consider if a sketch or other quick draft could suffice. You do not want to spend time or money on something that might be changed after testing.
Step 2: Build Your Prototype
Spend as many sessions as needed to prepare your prototype but only spend as much time as necessary so users can test your guide.
Step 3: Perform Prototype Testing
Reach out to Testers
Once the prototype is ready, it’s time to conduct prototype tests. Reach out to your confidants and target audiences to try to request their help. Follow the same guidelines as if you were requesting a review: Ask them if they would be willing to test your guide but be respectful of their time. When asking for their help, provide them with the amount of time and work involved before they commit. Only upon their acceptance of the critique should you provide them with the prototype (to avoid the risk of coming off as presumptuous).
You may orchestrate the tests so you are present to document the user’s experiences with your prototype or have them provide feedback after they test it. Either way, the goal is to receive feedback about what works or what needs work.
After receiving feedback, you may need to spend a journaling session or two to figure out what the feedback means, what changes are needed, and how best to implement those changes.
Repeat Prototype Tests
Ideally, you would be able to test a prototype until it requires no further changes. That’s not always feasible – especially if your pool of testers is limited. Cryptiquest recommends testing each iteration of your prototype until three tests for the same iteration prove no need for changes. Once this is achieved, you can move on to the next phase with a degree of confidence.
Okay. That’s a rough draft but it’ll do for now. I’ll place this content in the project document. I guess I also need to add a “Target Audience” section in the project document (added to the action items). The next session will focus on Implementation, Launch, and Beta Testing. See you there.
- Add Target Audience Section to the project document