Templates
Templates group into lifecycle phases. The flow below is the default path — each project picks the subset that fits.
GitHub issue (intake — not a template). Lives in the issue tracker, not the repo. Only graduates to a doc if it becomes a project.
- Business Case — scales with project size: light usage covers project-brief intake (problem + reasons + scope + risks); heavy usage adds full investment justification.
- Business Case Financial Model — produced only when financial analysis is material enough to warrant its own document.
- Takeover — receiving party fills in this template when inheriting an existing system or project. Same template as Phase 9 Handover (different perspective).
RFC, ADR, and Design Doc are not strictly linear. ADRs can crystallize during RFC, during Design Doc work, or after-the-fact during Implementation when an emergent decision needs capture.
- Test Plan — project-level, optional; runs parallel to the Design Doc because it depends on architecture choices to define environments and integration strategy. Required in regulated contexts (FDA, IEC 62304, ISO 13485, ISO 26262).
- Test Cases — per-feature, derived from the Planner's acceptance criteria (not from the Design Doc); drafted pre-code as the build contract. Can come before or after the DD depending on whether the design surfaces new edge cases.
Code gated by Test Cases. No template.
- Runbook — living document for handling systems and failures.
- Standard Operating Procedure — repeatable procedures for compliance and consistency.
- Project Status Update — recurring stakeholder reporting.
- Handover — outgoing party fills in this template when transferring out ownership at project closure or role change. Same template as Phase 3 Takeover (different perspective).
- Project Retrospective — outcomes and lessons captured at project end.
These three docs are never closed, but their update triggers differ:
- Tech Stack Overview — updated when an ADR changes a tech choice (new framework, swapped database, new observability stack, etc.).
- Architecture Overview — updated when system behavior or structure shifts. The Diátaxis Explanation doc — describes how an existing system, module, component, or area works for someone with zero prior context. Scope is flexible — multiple per repo: one for the whole app, others for specific sub-systems or areas of complexity.
- Data Dictionary — updated on any schema change (new table, new field, type change, removal). No ADR required; a migration is enough.
- Business Glossary — updated whenever new terminology enters the domain or an existing term's meaning shifts. No ADR or migration required.
- Post Incident Review (aka Postmortem) — system-lifetime, not project-bound. Accumulates against the running system over its whole life; a project can close while PIRs continue.
HR-adjacent docs. None of these live in the repo — they are personal or HR artifacts. Templates are linked below for use when needed.
- Role Brief — tech-team intake brief handed to HR / recruiting when opening a requisition. HR translates it into the public job posting (with compensation, benefits, EEO statement, application process).
- Brag Document — personal artifact for performance reviews and promotion cycles.
- Performance Improvement Plan — HR artifact for formal performance guidance.
None of these participate in the project lifecycle.
Use this canvas to clarify what you are building, why it matters, and what outcome you expect. It is a fast validation tool for the core problem, proposed solution, and expected impact.
Nono Weinzierl Product Expert – UX & Research @ Orbit http://www.orbitdigital.de/
Use this canvas to capture user research signals such as pains, motivations, quotes, and behaviors. It helps transform observations into actionable product insights.
Nono Weinzierl Product Expert – UX & Research @ Orbit http://www.orbitdigital.de/
Use this canvas to map how the idea creates, delivers, and captures value. It aligns customer segments, value propositions, channels, costs, and revenue streams in one view.
Use this storyboard to visualize the end-to-end user journey from first touchpoint to final value. It helps teams design meaningful moments, not just isolated features.
Nono Weinzierl Product Expert – UX & Research @ Orbit http://www.orbitdigital.de/
Use this canvas to translate strategy into execution by defining milestones, owners, resources, risks, and success criteria. It is the planning bridge between product vision and delivery.
| Order | Canvas | Purpose | Article Description |
|---|---|---|---|
| 1 | Idea Napkin | What are we building and why? | A one-page litmus test for your idea. It forces you to articulate the problem, solution, and benefits in a single view - with a brutal honesty check via the Importance/Effort/Impact scoring at the bottom. If you cannot fill this out clearly, you are not ready to build. |
| 2 | Insight Canvas | Who are we building for and what do they actually feel? | A deep-dive into your target user's world. Raw quotes, observed pains, desired gains - captured without interpretation first, then synthesized into key insights. This is where empathy meets data. Every feature decision traces back to something on this canvas. |
| 3 | Business Model Canvas | How does this become a business? | The classic Osterwalder framework adapted for your idea. Partners, activities, value propositions, customer segments, channels, revenue streams - all on one page. This is where cool idea becomes viable business. If the Revenue Streams box is thin, go back to canvas #2. |
| 4 | Product Storyboard | What does the user experience feel like? | A scene-by-scene walkthrough of how a real user encounters, uses, and benefits from your product. START -> scene -> END. This bridges the gap between abstract strategy (canvases 1-3) and concrete UX. It forces you to think in moments, not features. |
| 5 | Project Canvas | How do we execute this? | The operational reality check. Milestones, deliverables, success criteria, team, resources, risks - all mapped against the vision. This is the last canvas because it needs everything above as input. It turns vision into a plan with dates and accountability. |
The flow is: Idea -> User -> Business -> Experience -> Execution
- You cannot understand the user (#2) until you know what you are solving (#1).
- You cannot model the business (#3) until you understand the user's pains and gains (#2).
- You cannot storyboard the experience (#4) until you know the value propositions and channels (#3).
- You cannot plan execution (#5) until you have validated the experience makes sense (#4).
Each canvas answers a question that the next canvas assumes is already answered. Skip one and the downstream canvases have blind spots.
Use this template to script clear, structured tutorial videos with defined goals, key steps, narration, and expected learner outcomes.
© MyCompany. All rights reserved.
This software, including all source code and related documentation (the "Software"), is proprietary and confidential information of MyCompany.
TERMS OF USE: Access to and use of this Software is strictly limited to authorized employees and contractors of MyCompany and is governed by your Employment Agreement, Contractor Agreement, and/or Non-Disclosure Agreement (NDA) with MyCompany.
By accessing, copying, or using the Software, you acknowledge and agree that:
- All intellectual property rights in the Software are and shall remain the exclusive property of MyCompany.
- Unauthorized copying, distribution, or use of this Software is strictly prohibited and may result in immediate termination and severe civil and criminal penalties.
- You shall not attempt to reverse engineer, decompile, or otherwise discover the source code structure of any executable or binary parts of the Software.
DISCLAIMER OF WARRANTY: THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL MYCOMPANY BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY.
© 2026 MyCompany All rights reserved.
This software, including all source code and related documentation (the "Software"), is the proprietary and confidential information of MyCompany
TERMS OF USE: Access to and use of this Software is strictly limited to authorized employees, contractors, and licensees of MyCompany. Use is governed by your specific Employment Agreement, Contractor Agreement, License Agreement, and/or Non-Disclosure Agreement (NDA) with MyCompany.
INTELLECTUAL PROPERTY: All rights, title, and interest in and to the Software are the exclusive property of MyCompany. Unauthorized copying, distribution, or use is prohibited and may result in civil and criminal penalties.
RESTRICTIONS: You shall not attempt to reverse engineer, decompile, or otherwise discover the source code structure of the Software.
DISCLAIMER & LIMITATION OF LIABILITY: THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY. IN NO EVENT SHALL MYCOMPANY BE LIABLE FOR DAMAGES EXCEEDING THE TOTAL FEES PAID BY YOU FOR THE SOFTWARE. THIS AGREEMENT IS GOVERNED BY THE LAWS OF THE STATE OF FLORIDA.