Session 03: Drafting the Guide

Hi there. Welcome to this session of the How To Make Guides project where I am creating a public guide for making guides based on best practices. In the last session, the resources were researched, the content was outlined and the presentation principles were nailed down. In this session I’m going to build the content.

Here’s the outline from the last session. I’ll tackle each section, one at at time.

1. Title
2. Version
3. Summary
4. Requirements (if any)
5. Stages
   1. Planning
   2. Production
   3. Review
   4. Implementation
   5. Launch
   6. Retrospective
   7. Close
6. Appendix

I also need to keep this in mind:

• Voice. According to the Schenker, the words chosen should aim for a 6th – 8th grade reading level by using simple words, avoiding jargon, using conventional language. Within the article are links to readability tools such as this free Automatic Readability Checker.
• Layout. Design for mobile-first (one column) then move content to second columns for wider screens sensibly. Using images (as barriers) and smaller paragraphs can help chunk content into manageable sizes. According to Bath, section headers and numbered steps should also be used (this is obvious but the tips also go into how to write effective headers, etc.).

The Title

So what’s the title? According to Bath, the title should be easy to understand, use active language, include the direct action that the guide instructs, clarify the target audience when needed, and limited to 65 characters.

Some of the motivation on Bath’s part is to make guides so they work well within the confines of their website. Even so, some of those rationales translate to my needs, I think. There are other suggestions from the that I may ignore – don’t include the words “guide” or “how-to” in the title being one of them. While I might obey this tip in future guides, it seems like this specific one may require it.

I’m thinking the title should be something like:

Creating Guides

That title has an active voice and direct action. Maybe it should include something about project management. Perhaps something like:

Creating Guides the Cryptiquest Project Management Way

Yikes. Hate it. But I don’t hate the fact that there is a descriptor – just not that descriptor. Maybe it should be something a little catchier. Something like:

Creating Guides from Concept to Launch

Is that okay? It sounds like I’ve just created a tagline for Cryptiquest’s project management methodology and I’m uncomfortable with that. Or more likely, I’m uncomfortable just using a tagline without first doing the research to come up with one. BUT this does remind me that there will be a branding project later this year where there a tagline may manifest – or brand name at least – for all these guides and tools. So if the brand is something like “Project Mage” then the guide’s name will CHANGE from whatever it is after its launch to something like “Creating Guides using the CQ Project Mage Methodology” or “Creating Guides using Cryptiquest’s Project Runes” or whatever the brand is called after the branding guide’s launch.

My point, I guess, is that it’s going to change so it doesn’t really matter. “Creating Guides from Concept to Launch” works for now. Maybe it should be “…from Drive to Launch” – meaning the user has to be driven to produce and “we provide the rest”. I think that’s too much to convey at this point – I’ll save that for the branding project…

The Version

The version for this document will be 00.00.01. That’s easy enough.

The Summary

According to Bath, the summary should explain what the guide will instruct the users to do, clarify who the users are (if necessary), and do so within 160 characters. Here is where I can mention Cryptiquest Project Management methodology.

How to use Cryptiquest’s project management methods to conceptualize, plan, produce, and launch a guide designed to instruct users on a task or system.

Too wordy. Maybe start with the object then end with the descriptor. Cryptiquest does not need to be part of the summary, does it?

How to design, create, and launch an instruction manual to help users complete a task or a series of tasks.

Hmm… it’s worth noting that the summary guidelines from Bath differs from the overview guidelines from TIGR. Maybe creating guides and game instruction manuals are too different after all. The Bath summary is almost akin to a tagline of a game – or a one sentence recap of what the game is like. The TIGR overview is almost like a shortened version of the guide itself – explaining a summary of the goal, steps, and objectives for success (sounds similar to the project data discovered during the planning phase of Cryptiquest projects, oddly enough: goal, objectives, task steps, etc.).

What would a section like that look like for this guide? It wouldn’t use the planning phase data for the project itself. It would have to use goal/objectives for the user following the guide.

This guide provides step-by-step instructions to help you create a guide of your own. This guide incorporates Cryptiquest creative project management standards which provides a pathway from concept to launch. By following the process provided within this text, you will:

• identify what resources you need to make the guide;
• design the presentation parameters for your guide;
• draft and review the content for your guide;
• produce and test your guide;
• publish and launch your guide; and,
• debrief and officially close your guide project.

I like it. I don’t like how easily I’m incorporating “from concept to launch” into it. I have done no research on that phrase and it might already be a tagline for something. *Shakes fist at brain.*

Just did a quick search and that phrase is used all over the place, naturally. I really don’t want to work on taglines right now but I don’t think I can let it go. So I’m going to tackle that right now as quickly as I can…

• Creating Guides from Concept to Launch
• Creating Guides with Project Management
• Creating Guides with CQPM Standards
• Creating Guides with Gusto!
• Planning, Creating, and Launching Your Own Guides
• Running Guide Projects
• Managing Guide Projects
• Implementing Guide Projects
• Executing Guide Projects
• Producing Guide Projects
• Producing Guide Projects to Completion
• Producing Guide Projects to Realization
• Developing Guide Projects to Fruition

I think just “Producing Guide Projects” is good enough. “Producing ___ Projects” will be my shorthand for project management and ____ Guide ____ is the type of project being produced. Done and done.

Here is a new version of that overview text, with a replacement for that icky “from concept to launch” bit…

This guide provides step-by-step instructions to help you create a guide of your own. This guide incorporates Cryptiquest creative project management standards which provides a pathway from planning to publish. By following the process provided within this text, you will:

• identify what resources you need to make the guide;
• design the presentation parameters for your guide;
• draft and review the content for your guide;
• produce and test your guide;
• publish and launch your guide; and,
• debrief and officially close your guide project.

Requirements

Right away I dislike the word “requirements”. I think it sounds too aggressive. Something like “Before You Begin” is a more accessible but the problem is that it’s less direct. To modify it I suppose it could be something like “What You Need Before You Begin” or “What You Need To Start”.

Looking back, this section is not from Bath but from TIGR. Specifically, it’s the Components section for game rule books which I converted to “Requirements”. I suppose my point here is that there isn’t much guidance for this aside from the suggestion that headings follow the same principles as writing titles. So, let’s review those.

According to Bath, the title should be easy to understand, use active language, include the direct action that the guide instructs, clarify the target audience when needed, and limited to 65 characters.

Following the principles, something like “Meeting Requirements” would match the original title. I’m not sure what the equivalent would be in the original source “Components”.

• Verifying Components
• Reviewing Game Components
• Assessing Materials
• Taking Inventory of Components
• Reviewing Component Manifest
• Inspecting Component Inventory
• Inspecting Component List

Oh wait. I forgot that sometimes it’s not about game components. Sometimes requirements are prerequisite steps or materials needed before you start. So what do I do about that?

• Preparing For This Endeavor

You know what. Done. I like that. “This Endeavor” is a placeholder for what the guide is instructing. It would probably work best if the actual word was a noun version of the verb (whatever the term is for that). For this guide, it would be “Preparing For Guide Production”. A guide called “Playing Poker Games” it might be “Preparing For Game Play”. When it comes to proper nouns, the noun itself is probably good. The requirement section for a guide called “Playing the Game of Checkers” could be called “Preparing for a Game of Checkers”. “Playing the Imbue Role-playing Game” = “Preparing for the Imbue Role-playing Game”.

Seems okay for now.

But what requirements are there for producing guide projects? Aside from needing something to create a guide for?

Oh. Maybe the guide should literally be just for production and the requirements can be something that the project planning guide is used to discover? That doesn’t make sense. I keep getting confused between the requirements for the guide and the requirement section that will be explained in the guide. Ha.

Anyway, what are the requirements for creating a guide?

• Steps Taken: N/A
• Materials Provided: N/A
• Materials Needed: Means for documentation

I guess that’s good for now.

Stages

The idea is that this will follow Cryptiquest Project Management guidelines. A thing that is missing and I just remembered now is a TESTING phase – where producers would test the guide with users after it’s been produced. The stages would be customized and tailored specifically for guide projects.

Below is the results thus far. I will plan this all out in the next session. See you there!

Action Items

• Add a Testing Phase to Project Planning Guidelines, etc.

---

Producing Guide Projects

version 00.00.01

How to design, create, and launch a guide to help users complete a task or a series of tasks.

Overview

This guide provides step-by-step instructions to help you create a guide of your own. This guide incorporates Cryptiquest creative project management standards which provides a pathway from planning to publish. By following the process provided within this text, you will:

• identify what resources you need to make the guide;
• design the presentation parameters for your guide;
• draft and review the content for your guide;
• produce and test your guide;
• publish and launch your guide; and,
• debrief and officially close your guide project.

Preparing for Guide Production

In addition to this guide, and a need for producing a guide of your own, you will need means to create documentation.