Loading...
Create a comprehensive technical design document that records decisions, communicates trade-offs, and converges on implementation strategy before coding.
# Technical Design Document (Design Doc) Generator ## Problem Context Engineers need to create technical design documents before implementing features. Design docs help: - **Solidify reasoning** - Writing is thinking; formalizing your approach improves the solution - **Improve the design** - Get feedback from peers (like code review, but for design) - **Create consensus** - Align stakeholders on what should be built - **Record decisions** - Document trade-offs, alternatives considered, and open questions for posterity ## Solution Pattern: Template Pattern + Chain-of-Thought This prompt uses a structured template to guide you through creating a comprehensive design doc, with step-by-step reasoning for each section. ## Prompt Template Act as a senior software engineer specializing in technical design. I need to create a Technical Design Document (Design Doc) for [feature/system name]. Guide me through creating a comprehensive design doc with the following sections: ### 1. Overview - **Title**: [Feature/System Name] - **Author(s)**: [Your name/team] - **Date**: [Date] - **Status**: [Draft/Review/Approved/Implemented] - **Stakeholders**: [List key stakeholders who need to review] - **Related Documents**: [Links to PRD, RFCs, or other relevant docs] ### 2. Problem Statement - What problem are we solving? - Why is this problem important? - What is the current state, and why is it problematic? - What evidence do we have that this problem exists? - Who is affected by this problem? ### 3. Goals & Non-Goals - **Goals**: What are we trying to achieve? - Primary goal - Secondary goals - **Non-Goals**: What are we explicitly NOT trying to solve? - Out of scope items - Future considerations (document but defer) ### 4. Proposed Solution - High-level architecture overview - Key components and their responsibilities - Data flow and interactions - Technology choices and rationale - Diagrams (architecture, sequence, data flow) - describe what should be included ### 5. Detailed Design - **Component Design**: Detailed breakdown of each component - Interfaces and APIs - Data structures - Algorithms and logic - **Database Schema**: Tables, indexes, relationships (if applicable) - **API Design**: Endpoints, request/response formats, error handling - **Security Considerations**: Authentication, authorization, data protection - **Performance Considerations**: Scalability, latency, throughput requirements ### 6. Alternatives Considered For each alternative solution: - **Option Name**: Brief description - **Pros**: Advantages - **Cons**: Disadvantages - **Why Not Chosen**: Rationale for rejection ### 7. Trade-offs & Risks - **Trade-offs**: What are we sacrificing for this solution? - **Risks**: What could go wrong? - Technical risks - Timeline risks - Resource risks - **Mitigation Strategies**: How will we address each risk? ### 8. Implementation Plan - **Phases**: Break down into phases or milestones - **Dependencies**: What needs to be done first? - **Timeline**: Estimated timeline for each phase - **Resource Requirements**: Team members, infrastructure, tools ### 9. Testing Strategy - **Unit Tests**: What needs unit test coverage? - **Integration Tests**: What integration points need testing? - **Performance Tests**: What performance benchmarks need to be met? - **Monitoring & Observability**: What metrics and alerts do we need? ### 10. Rollout Plan - **Deployment Strategy**: Canary, blue-green, feature flags? - **Rollback Plan**: How do we roll back if something goes wrong? - **Success Criteria**: How do we know the rollout was successful? ### 11. Open Questions - Questions that need answers before implementation - Decisions that need to be made - Research or proof-of-concept work needed ### 12. Future Work - Known limitations of this design - Future improvements or optimizations - Technical debt introduced --- **Instructions:** 1. For each section, ask me clarifying questions if needed 2. Provide clear, actionable content for each section 3. Use markdown formatting for readability 4. Include code examples, diagrams descriptions, and data structures where relevant 5. Ensure the design doc is comprehensive yet concise 6. Focus on recording decisions and trade-offs, not just describing what will be built Once complete, format the design doc in a clean, professional structure that I can share with stakeholders and use as a decision record. --- *This prompt is part of the Engify.ai research-based prompt library. Design docs are created BEFORE implementation to converge on solutions. They serve as decision records AFTER implementation.*
Get access to enhanced versions, advanced examples, and premium support for this prompt.
Loading revision history...
Apply what you learned with these prompts and patterns
Acts as a critical Red Team consultant to pressure-test your product strategy, identify hidden assumptions, uncover potential weaknesses, and validate market fit before presenting to executives or committing resources.
Generate comprehensive API documentation with examples and error cases
Deep dive into prompt engineering with our comprehensive masterclass covering all patterns and techniques.
Prompt Engineering Masterclass: Complete Guide for Developers