> ## Documentation Index > Fetch the complete documentation index at: https://docs.stage3.app/llms.txt > Use this file to discover all available pages before exploring further. # Blueprints vs Guides > Understanding the key differences between blueprints and guides and when to use each ## Two Types of Documentation MPQA offers two ways to document different levels of your process: * **Blueprints** - Category-level documentation that provides context and overview for a group of related activities * **Guides** - Activity-level documentation that provides step-by-step instructions for individual tasks Both serve different purposes and use the same rich text editor for creating documentation with version history. Think of blueprints as the "why" and guides as the "how." Blueprints explain the big picture for a category; guides explain specific steps for an activity. ## Quick Comparison | Feature | Blueprints | Guides | | -------------------- | -------------------------------------------------- | ------------------------------------------------ | | **Scope** | Entire category | Single activity | | **Purpose** | Context and overview | Step-by-step instructions | | **Attached to** | Activity categories | Individual activities | | **Access from** | "Blueprint" button on category bar in Process Flow | Click activity name or access from activity view | | **Editor** | Rich text editor with version history | Rich text editor with version history | | **Special features** | Metadata sidebar with Blueprint Details | Forms sidebar - can attach forms to guides | | **Best for** | Training, onboarding, category context | Execution, task completion, detailed procedures | | **Audience** | Everyone involved in the category | Person performing the specific activity | ## Blueprints Explained Blueprints are groupings of related Guides and provide high-level documentation for a phase or stage in your process. ### Accessing Blueprints Go to your core process and click the **Visual** tab to see the Process Flow diagram. Each category appears as a colored horizontal bar (e.g., red, green, blue) with the category name on the left. On the right side of the category bar, click the **"Blueprint"** button. This opens the Blueprint editor for that category. ### Blueprint Editor Interface When you open a blueprint, you'll see: **Top navigation:** * Title showing category name (e.g., "E - Blueprint") * Breadcrumb: Process > Sub-process > Category name * Action buttons: Back to RACI, Workflow, KPIs, Delete Blueprint, Create SOP **Main area:** * Rich text editor with full formatting toolbar * Menu bar: File, Edit, View, Insert, Format, Tools, Table, Help * Placeholder text: "Start typing..." **Left sidebar:** * **Version History** showing all saved versions **Right sidebar:** * **Metadata** section with: * Version Info (version number, created date, created by) * Blueprint Details (type: Blueprint, parent category) ### What Blueprints Contain Explain what this category of activities accomplishes and why it exists. **Example:** A blueprint for "Discovery Phase" might explain your company's approach to understanding customer needs, the questions you aim to answer, and how discovery impacts the overall sales process. This gives everyone context before diving into specific activities. What are you trying to accomplish with this group of activities? **Example:** "The goal of the screening phase is to identify the top 10% of applicants who meet our technical requirements and culture fit, reducing interview time while maintaining quality of hires." Clear objectives help team members understand success criteria. Important rules, compliance requirements, or best practices that apply to all activities in this category. **Example:** "All screening decisions must be documented in the ATS. Avoid questions about protected categories. Use the standardized rubric for all candidates to ensure fair evaluation." This ensures consistent application of policies across all category activities. What systems, templates, or resources do team members need for this category? **Example:** "This phase uses our Contract Management System (link). Required templates: Legal Review Checklist (link), Pricing Comparison Spreadsheet (link). Training video available here (link)." Providing resources upfront prevents interruptions during execution. How does this category fit into the larger process? What comes before and after? **Example:** "Discovery happens after initial qualification but before proposal development. Information gathered here directly informs our pricing and solution design." Context helps people understand their role in the bigger picture. ### When to Use Blueprints When a category involves multiple activities that need context to understand why they exist and how they work together. When onboarding people who need to understand the "why" behind activities before jumping into execution. When there are important rules, regulations, or policies that apply to all activities in the category. When you need to explain how this category of activities supports business goals or company strategy. ## Guides Explained Guides are attached to individual activities and provide detailed, step-by-step instructions for completing that specific task. ### Accessing Guides Go to your core process and find the specific activity you want to document. You can access activities from the RACI matrix or Process Flow diagram. Click on the activity name to open its detailed view. Look for the Guide section or click a "Create Guide" option. This opens the Guide editor for that activity. ### Guide Editor Interface When you open a guide, you'll see: **Top navigation:** * Title showing activity name (e.g., "e - Guide") * Breadcrumb: Process > Sub-process > Activity name * Action buttons: Back to RACI, KPIs, Create SOP **Main area:** * Rich text editor with full formatting toolbar (identical to Blueprints) * Menu bar: File, Edit, View, Insert, Format, Tools, Table, Help * Placeholder text: "Start typing..." **Left sidebar:** * **Version History** showing all saved versions **Right sidebar:** * **Forms** section with: * "+ Add New Form" button * Note: "Guide SOP Required - Create a guide SOP first before adding forms" Guides have a unique Forms feature that Blueprints don't have. You can attach forms to guides to collect structured data during activity execution. ### What Guides Contain Clear, sequential steps to complete the activity from start to finish. **Format:** 1. \[Action verb] \[what to do] - Brief explanation 2. \[Action verb] \[what to do] - Include system names or field names 3. \[Action verb] \[what to do] - Add important considerations **Example for "Screen Resume":** 1. Open the ATS and navigate to the job posting 2. Review resume against minimum qualifications checklist 3. Score candidate using the rubric (0-5 scale) 4. If score is 4+, click "Advance to Phone Screen" 5. If score is 3 or below, click "Reject" and select reason from dropdown Numbered steps make it clear what order to follow. What to do when faced with choices, exceptions, or different scenarios. **Format:** * **If \[condition], then \[action]** * **If \[different condition], then \[different action]** **Example:** * **If candidate lacks one required skill but excels in all others:** Flag for hiring manager review before rejecting * **If resume shows job-hopping (5+ jobs in 5 years):** Note in review comments for interview discussion * **If candidate requests remote work:** Verify position allows remote before advancing Decision points prevent confusion when standard procedure doesn't cover all situations. Show exactly what buttons to click, forms to fill out, or what the result should look like. **Use screenshots for:** * System interfaces showing specific fields or buttons * Correctly filled forms as examples * Expected results after completing the activity Visual guides are faster to follow than text descriptions and reduce errors. Helpful advice to work more efficiently or avoid common mistakes. **Examples:** * **Tip:** Focus on quantifiable achievements rather than job duties when reviewing resumes * **Tip:** Schedule contract reviews for morning hours when Legal team is most responsive * **Common mistake:** Don't reject candidates for minor typos in creative roles * **Best practice:** Keep frequently-used templates bookmarked for quick access These insights come from experienced team members who've found better ways to work. Specific tools, templates, or resources needed for this individual activity. **Examples:** * Resume screening rubric template (link) * ATS system login (link to system) * Rejection email templates (link to templates) * Qualification checklist (link to checklist) Direct links save time and ensure people use the right resources. ### Guide Forms Feature Guides have a unique capability that Blueprints don't have: **Forms**. **What are Forms?** Forms allow you to attach structured data collection to an activity guide. This could be: * Checklists that must be completed during the activity * Data entry forms for capturing specific information * Quality control forms for verifying work * Approval forms for sign-offs **Requirement:** Before you can add forms to a guide, you must first create a guide SOP. This ensures the procedural documentation exists before adding structured data collection. The Forms sidebar shows: "Guide SOP Required - Create a guide SOP first before adding forms." ### When to Use Guides Activities performed regularly that benefit from standardized, documented steps to ensure consistency. Multi-step activities where mistakes are costly and detailed instructions prevent errors. Activities that involve navigating specific tools, platforms, or interfaces where screenshots are valuable. When new employees need clear instructions to learn how to perform tasks independently. ## Blueprints vs Guides: Key Differences Understanding when to use each type of documentation: **Blueprints: Category-Level** Cover a group of related activities that form a phase or stage of your process. Example: "Candidate Screening" category might include activities like "Review Resume," "Phone Screen," "Check References" The blueprint provides context for all these activities together. **Guides: Activity-Level** Cover one specific task within your process. Example: "Review Resume" is a single activity The guide provides step-by-step instructions for just that one task. **Blueprints: Why & Context** Answer questions like: * Why does this category exist? * What are we trying to achieve? * What policies apply to these activities? * How does this fit into the larger process? **Guides: How & Execution** Answer questions like: * What are the exact steps? * Where do I click? * What do I do if X happens? * What tools do I need? **Blueprints: Team-Level** Read by: * Everyone involved in the category * New team members learning the process * Managers understanding team workflows * Stakeholders understanding process design **Guides: Performer-Level** Read by: * The person actually performing the activity * Someone learning to do the specific task * Quality reviewers checking if steps were followed * Trainers teaching the procedure **Blueprints: Narrative & Explanatory** Written in paragraphs explaining concepts, providing background, and establishing context. Uses prose to help readers understand the thinking behind decisions. **Guides: Procedural & Instructional** Written in numbered steps with clear actions. Uses imperative voice: "Click this," "Enter that," "Review these" Focuses on execution, not explanation. ## Can You Use Both? **Yes!** Blueprints and guides serve different purposes and work very well together. The category is complex enough to need context AND individual activities require detailed instructions. **Example: Employee Onboarding** **Blueprint for "First Week Training" category:** * Goals for the first week * Creating a welcoming experience * Legal requirements to complete * Company culture and values * Training philosophy **Guides for individual activities:** * "Set up email account" - Step-by-step system instructions * "Complete tax forms" - Form-by-form guidance * "Meet with manager" - Agenda and talking points * "System access requests" - Exactly what to request and where The blueprint gives new hires context about why their first week matters. The guides ensure they complete each task correctly. The category needs explanation but individual activities are simple and self-explanatory. **Example: Executive Approval Category** **Blueprint needed:** * What requires executive approval and why * Approval criteria and thresholds * Escalation process * Expected response times * How to prepare materials for executives **Guides not needed:** * "Submit to CEO" - Just attach document and send email (obvious) * "Await decision" - No procedural steps to document * "Communicate decision" - Standard communication, no special procedure The value is in understanding the approval criteria, not in documenting simple actions. The category purpose is obvious but specific activities have complex procedures. **Example: Data Entry Category** **Blueprint not needed:** * Everyone knows data entry means entering data * Purpose is self-evident * No special policies beyond standard data handling **Guides needed:** * "Enter customer information" - Specific fields, validation rules, where to find data * "Import batch records" - System steps, file format requirements, error handling * "Verify data accuracy" - Checking procedures, acceptable error rates Focus on making sure people do the tasks correctly, not explaining why data entry exists. The process is simple and obvious to everyone on the team. **Example: Simple approval with minimal steps** Activities like "Review document" and "Click approve button" may not need documentation if: * The team is experienced * The system is intuitive * There are no special policies * Mistakes have low impact Don't create documentation just for the sake of documentation. Create it when it adds value. ## Documentation Strategy Here's how to think about documentation for your processes: Define your activities and assign RACI roles first. This clarifies what work happens and who does it. Look for categories that: * Have multiple related activities * Require understanding of policies or compliance * Need context for new team members * Support strategic business goals These benefit from Blueprints. Look for activities that: * Have multiple steps * Use specific systems or tools * Have decision points or variations * Are performed by different people at different times These benefit from Guides. Don't try to document everything at once. Start with: 1. Most important categories (Blueprints) 2. Most complex activities (Guides) 3. Most error-prone activities (Guides) 4. Fill in remaining documentation over time ## Best Practices Reference guides in your blueprints and vice versa. Create a connected documentation system. Don't repeat information in both blueprints and guides. Keep category-level info in blueprints, activity details in guides. Review documentation when processes change. Set quarterly review reminders. Ask team members if documentation is helpful. Update based on their questions and confusion. Common mistake: Creating duplicate documentation at multiple levels. Choose the right level (category vs activity) and keep information there, then link between documents rather than copying content. ## Documentation Hierarchy Here's how all documentation types relate in MPQA: **Process Level: SOP** * Standard Operating Procedure covers the entire core process * High-level purpose, scope, and flow * Links to category blueprints **Category Level: Blueprint** * Provides context for a group of related activities * Why this category exists and what it accomplishes * Policies that apply to all activities in the category * Links to activity guides **Activity Level: Guide** * Step-by-step instructions for one specific activity * How to complete this task correctly * Tools, templates, and resources for this activity * Can have forms attached for data collection ## Next Steps Learn how to create category blueprints Learn how to create activity guides Learn how to create process SOPs