# Complex SaaS Feature Documentation Architecture

Public URL: https://amo.ng/prompts/complex-saas-feature-documentation-architecture

Summary: Plan documentation for complex SaaS features across user guides, admin docs, release notes, support workflows, edge cases, and maintenance ownership.

Use this for: Use this to design documentation architecture for a complex product feature before writing pages.

Category: Productivity
Tool: Claude
Difficulty: Advanced
Prompt type: knowledge management

## Best Use Cases

1. SaaS Documentation Planning
2. Feature Documentation Architecture
3. Admin Guide Planning
4. User Guide Planning
5. Release Notes Planning
6. Support Enablement
7. Knowledge Base Structure
8. Product Education

## Prompt Body

You are a technical documentation architect for SaaS products.

## Task
Design a documentation architecture for a complex SaaS feature so different user roles can understand, adopt, configure, troubleshoot, and support the feature.

## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.

- [Feature description]
- [User roles]
- [Admin capabilities]
- [Known edge cases]
- [Support tickets]
- [Release scope]
- [Product terminology]
- [Screens or flows]
- [Compliance notes]
- [Documentation platform]

## Important Constraints
- Do not invent product behavior, screenshots, permissions, compliance requirements, support history, or release details.
- Separate confirmed feature behavior from assumptions and documentation recommendations.
- Make the documentation architecture specific to the feature, user roles, admin capabilities, edge cases, and release scope.
- Include docs for users, admins, support teams, release notes, and internal handoff where relevant.
- Flag any product behavior or compliance claim that requires product, legal, security, or support review.
- Each proposed document must have a clear audience, purpose, owner, and update trigger.
- Avoid generic documentation advice. Produce a practical structure that can be assigned and written.

## Step-by-Step Task Instructions

1. Restate the feature, release scope, user roles, admin capabilities, known edge cases, support tickets, terminology, documentation platform, and constraints.

2. Build an audience and task map:
   - Who needs the documentation
   - What each audience is trying to do
   - What each audience already knows
   - What each audience may misunderstand
   - What content each audience needs

3. Design the documentation set:
   - User guide
   - Admin guide
   - Setup or configuration guide
   - Troubleshooting article
   - FAQ
   - Release notes
   - Support workflow notes
   - Internal enablement notes
   - Compliance or security notes, if relevant

4. Create the information architecture:
   - Recommended navigation
   - Article grouping
   - Cross-links
   - Search terms
   - Terminology rules
   - Where screenshots or flow diagrams are needed

5. Create article briefs for each document:
   - Audience
   - Job to be done
   - Outline
   - Required inputs
   - Edge cases to cover
   - Owner
   - Reviewers
   - Update trigger

6. Create a maintenance plan:
   - Who owns updates
   - What changes should trigger doc review
   - How support tickets should feed back into docs
   - How release notes should connect to long-term documentation

## Output Format

### Audience and Task Map
Use a table with:
- Audience
- Primary task
- Likely confusion
- Required documentation
- Priority

### Documentation Set
Use a table with:
- Document
- Audience
- Purpose
- Owner
- Reviewers
- Update trigger

### Information Architecture
Show the recommended structure, navigation, cross-links, and search terms.

### Article Briefs
Provide concise briefs for each proposed document.

### Support and Troubleshooting Coverage
List common issues, edge cases, support workflows, and escalation notes.

### Release Notes and Internal Enablement
Explain what should go into release notes, support handoff, and internal training.

### Maintenance Plan
Define ownership, review cadence, update triggers, and feedback loops.

### Human Review Notes
List assumptions, missing inputs, risky claims, and items requiring product, support, legal, security, or compliance review.

## Verification
Before finalizing, check that:
- Each document has a clear audience, job, owner, and update trigger.
- Admin, user, support, and release-note needs are covered.
- Known edge cases and support tickets are reflected.
- Product terminology is consistent.
- No unsupported product, legal, security, or compliance claims are invented.
- Missing inputs and human review items are clearly listed.

## Final Instruction to Begin
Begin now. If key product context is missing, ask for it first. Otherwise, produce the full documentation architecture in the requested markdown format.

## Variables to Replace

1. Feature description
2. User roles
3. Admin capabilities
4. Known edge cases
5. Support tickets
6. Release scope
7. Product terminology
8. Screens or flows
9. Compliance notes
10. Documentation platform

## How to Use

Paste this prompt into Claude with the feature description, user roles, admin capabilities, release scope, edge cases, support tickets, product terminology, screens or flows, compliance notes, and documentation platform filled in. Use the output as a planning brief before writing the actual documentation pages.

## Example Use Case

A B2B SaaS company is releasing granular permissions and needs a documentation plan covering admin setup, user behavior, support troubleshooting, release notes, edge cases, and internal enablement.

## Tags

1. saas-documentation
2. docs-architecture
3. claude
4. knowledge-management
5. release-notes
6. support-enablement
7. admin-docs
8. user-guides
9. information-architecture
10. product-education

## Dates

Published: 2026-07-03
Updated: 2026-07-03