This page is intended to function as copy-paste-helper for note-taking, brainstorming, refreshing memory or simply for inspiration.
Use when tracking a discrete, time-boxed deliverable that has measurable outcomes and defined ownership.
<!--
template_type: milestone
project: [project_name]
status: [planning|active|completed]
priority: [high|medium|low]
-->
# Milestone: [milestone_name]
**Status:** In Progress | On Track | At Risk | Complete
- **Target Date:** [YYYY-MM-DD]
- **Completion Date:** [YYYY-MM-DD]
- **Objective:** [what this milestone achieves]
- **Effort Estimate:**
- Total hours: [hours]
- Team members needed: [count]
- **Key Results:**
- [ ] **KR1** (Priority: [high|medium|low]): [description]
- Success criteria: [measurable condition]
- Owner: [person]
- **Context & Dependencies:**
- Related milestones: [links or references]
- Dependencies: [what must be completed first]
- Stakeholders: [people to involve or inform]
- **Tripwires:**
- [risk condition → contingency action]
- **Reviews:**
- **[YYYY-MM-DD] - [weekly|milestone|retrospective]:**
- **Completion Rate:** [percentage]
- **What went well:** [wins]
- **Challenges faced:** [obstacles]
- **Lessons learned:** [insights]
- **Action plan:** [next steps with owners and deadlines]
Use to align a team around a single objective with a short list of measurable key results for a defined period.
<!--
template_type: okr
project: [project_name]
status: [planning|active|completed]
-->
# OKR: [okr_name]
Objective:
- [clear statement of what is to be achieved]
Key Results:
- [ ] kr_1: [measurable outcome]
- success_criteria: [metric or condition that denotes success]
- owner: [person responsible]
Review Date:
- [YYYY-MM-DD]
Context & Dependencies:
- related_items: [links or references to related work]
- dependencies: [what must be completed before this OKR can succeed]
Notes:
- [optional additional context]
Use to communicate high-level initiative sequencing and major milestones across a planning horizon.
<!--
template_type: roadmap
project: [project_name]
status: [planning|active|completed]
priority: [high|medium|low]
-->
# Roadmap: [roadmap_name]
- **Timeframe:** [YYYY-MM-DD] to [YYYY-MM-DD]
- **Key Initiatives:**
- **Initiative 1:**
- [description]
- [timeline or duration]
- **Milestones:**
- [list of major milestones with dates]
Use to document a strategic business goal with measurable success criteria and a clear rationale.
<!--
template_type: business_goal
project: [project_name]
status: [draft|active|achieved|deprecated]
priority: [high|medium|low]
-->
# Business Goal: [business_goal_name]
- **Objective statement:** [clear, measurable outcome the goal aims to achieve]
- **Supporting metrics:** [KPIs, e.g., MTTR, MTBF, revenue targets]
- **Strategic importance:** [why this goal matters for the business]
- **Target date:** [YYYY-MM-DD]
- **Review date:** [YYYY-MM-DD]
- **Dependencies:** [related factors, systems, or other goals that impact this goal]
Use when mapping an existing workflow to identify pain points, triggers, and opportunities for improvement.
<!--
template_type: business_process
domain: [domain_area]
status: [analysis|design|implementation|review]
priority: [high|medium|low]
-->
# Business Process: [process_name]
- **Stages:**
- [stage_1]
- [stage_2]
- **Pain Points:**
- [pain_point]
- **Opportunities:**
- [opportunity]
- **Inputs / Triggers:**
- [trigger]
- **Outputs / Results:**
- [output]
- **Key Stakeholders:**
- [stakeholder]
Use to define decision-making authority, policies, roles, and review cadence for an organization or initiative.
<!--
template_type: governance_model
organization: [organization_name]
status: [draft|active|under_review|archived]
priority: [high|medium|low]
-->
# Governance Model: [governance_model_name]
- **Decision-Making Structure:**
- [primary decision-making authority]
- **Policies:**
- [key guiding policy or principle]
- **Roles & Responsibilities:**
- [role and responsibilities]
- **Review Cycle:** [quarterly|annually|...]
Use to map stakeholder groups, their roles, and relative influence at the start of a project.
# Stakeholder Map
| Stakeholder | Role | Interest/Influence | Allocation (%) |
| ------------ | ------ | ------------------ | -------------- |
| [Name/Group] | [Role] | [High/Medium/Low] | [Percentage] |
Use to articulate a long-term strategic plan, including vision, purpose, themes, and goals.
Strategy is a set of integrated choices about where to play and how to win. It is not a goal, a wish, or a to-do list. A goal says where you want to end up; a strategy explains the logic for why you will get there and what you will sacrifice to do so.
A good strategy has three parts (Rumelt's kernel):
What strategy is not:
A useful test: can you articulate what you are not doing, and why? If every option still seems open, you have not made a choice yet.
<!--
template_type: strategy
organization: [organization_name]
status: [draft|active|under_review|archived]
priority: [high|medium|low]
-->
# Strategy: [strategy_name]
- **Vision, Future & Impact**
- **Aspiration:** [inspiring statement of the future we aim to create]
- **Future Success:** [measurable outcomes that define success]
- **Impact on Stakeholders:** [how vision benefits customers, employees, and community]
- **Purpose & Core Beliefs**
- **Purpose:** [why we exist and what impact we want to make]
- **Core Values:** [fundamental principles guiding decisions and behavior]
- **Guiding Principles:** [strategic beliefs driving our actions]
- **Strategic Themes**
- **Theme 1:** [major focus area aligned with our vision]
- **Ambition & Goals**
- **Short-Term:** [measurable goals for 1-3 years]
- **Long-Term:** [transformative aspirations for 5-10 years]
- **Narrative & Differentiation**
- **Innovation & Differentiation:** [how we create unique value]
- **Story:** [journey, challenges, and vision — the "why" and "what"]
Use at the start of any project to pressure-test scope, value, and feasibility before committing resources.
<!--
template_type: project_pre_work_questions
project: [project_name]
status: [planning|in_progress|completed]
priority: [high|medium|low]
-->
# Key Questions Before Starting the Work: [project_name]
- **What is worth it?**
- What can we realistically achieve given our constraints? [achievability_assessment]
- Will all items return the investment for the organisation? [organizational_roi]
- Will all items be worth our time, budget and resources? [team_value_assessment]
- Will all items bring real value to users? [user_value_proposition]
- Can we support and maintain the work after launch? [post_launch_capabilities]
- **What are we doing?**
- Is the goal understandable to all involved? [goal_clarity]
- Is the current plan and content accessible to all involved? [plan_accessibility]
- Is the timeline and milestones clear to all involved? [timeline_clarity]
- **What is the value of the outcome?**
- Who are we creating value for? [target_audience]
- What is the underlying critical need we aim to address? [critical_need]
- How does the outcome differentiate from alternatives? [competitive_differentiation]
Use when stepping into a project already in motion. Fill it in over the first days of onboarding — treat it as a living document until you have answers.
<!--
template_type: joining_existing_project
project: [project_name]
status: [draft|completed]
-->
# Joining: [project_name]
- **Date joined:** [YYYY-MM-DD]
- **My role:** [what I am here to do]
## The project
- What is the goal, and why does it exist? [goal]
- Where does it stand today — what has been shipped, what is in progress? [current_state]
- What has been tried and abandoned, and why? [history]
- What are the biggest open risks or unresolved problems? [risks]
- What are the most important decisions already made, and what led to them? [key_decisions]
- What does success look like in 3 and 12 months? [success_criteria]
## The team
- Who are the key people and what are their roles? [people]
- How does the team communicate and make decisions? [ways_of_working]
- Who should I talk to first, and about what? [first_conversations]
- Are there any known tensions or difficult dynamics to be aware of? [dynamics]
## The work
- What is the immediate next milestone or deadline? [next_milestone]
- What is the current priority order of the backlog? [priorities]
- What is blocked right now, and why? [blockers]
- What work is mine to own from day one? [my_immediate_scope]
## Access and orientation
- What tools, repos, docs, and systems do I need access to? [access_needed]
- Where does documentation live? [docs_location]
- Are there any onboarding materials, runbooks, or guides? [existing_guides]
## Open questions
- [question I still need to answer]
Use to craft a concise value proposition statement for a product or service.
<!--
template_type: pitch
product: [product_name]
status: [draft|active|under_review|archived]
priority: [high|medium|low]
-->
# Pitch: [product_service_name]
For **[target_audience]** who need **[opportunity or pain point]**, **[product_service]** provides **[solution]**. Unlike **[alternatives]** it **[differentiators]**.
Use to compare your product or service against alternatives on the dimensions that matter most to your target audience.
<!--
template_type: competitive_analysis
project: [project_name]
status: [draft|active|completed]
priority: [high|medium|low]
-->
# Competitive Analysis: [topic]
| Dimension | Us | [Competitor 1] | [Competitor 2] |
| --------- | -- | -------------- | -------------- |
| [e.g. Price] | [value] | [value] | [value] |
| [e.g. Target audience] | [value] | [value] | [value] |
| [e.g. Key differentiator] | [value] | [value] | [value] |
**Key takeaways:**
- [what we do better]
- [where we fall short]
- [gaps in the market no one is addressing]
Use before writing or assigning a task to ensure it is well-scoped, clearly owned, and actionable.
# Task Design & Formulation Checklist
## Clarity & Purpose
- [ ] **Is the task clearly defined?**
What exactly needs to be done? Can it be misunderstood?
- [ ] **Is the goal or outcome explicit?**
What does "done" look like?
- [ ] **Why is this task important?**
Does it connect to a larger goal or value?
## Scope & Size
- [ ] **Is the task the right size?**
Can it be completed in a single sitting/day/sprint?
- [ ] **Can it be broken down further?**
Would smaller subtasks improve focus or momentum?
## Context & Dependencies
- [ ] **Are all necessary inputs/resources identified?**
What do I need to start and finish this?
- [ ] **Are there any dependencies?**
Does this rely on someone/something else first?
## Ownership & Responsibility
- [ ] **Is it clear who owns this task?**
Who is responsible for completing it?
- [ ] **Is it delegated appropriately?**
Does the person have the skills and context needed?
## Time & Priority
- [ ] **Is there a due date or time estimate?**
When should it be done? How long might it take?
- [ ] **Is it urgent or important (or both)?**
How does this rank among other tasks?
## Motivation & Friction
- [ ] **Is the task intrinsically motivating or rewarding?**
Is there something engaging about it?
- [ ] **Are there potential blockers or friction points?**
What might make someone hesitate to start or finish?
Use to document observations from a field study or user interview conducted in the user's natural environment.
<!--
template_type: contextual_inquiry
project: [project_name]
status: [planned|in_progress|completed]
priority: [high|medium|low]
-->
# Contextual Inquiry: [inquiry_name]
## Session Information
- **Date & Time:** [YYYY-MM-DD HH:MM]
- **Location/Setting:** [where the session takes place]
- **Objective:** [main focus of this session]
- **Context:** [related project or design track]
## Participant Details
- **Name:** [name or pseudonym]
- **Role/Background:** [user's role or relevant background]
- **Contextual Factors:** [experience level, familiarity with the product, etc.]
## Environment & Setup
- **Environment:** [physical and digital environment]
- **Devices & Tools:** [devices, software, or tools used]
- **Setup/Configuration:** [workspace setup or configuration notes]
## Observed Tasks & Behaviors
- **Tasks:**
- [task observed]
- **Task Duration & Sequence:** [time taken or order of tasks]
- **Behaviors & Interactions:** [how the participant interacts with the system]
## User Feedback & Quotes
- **Direct Quotes:**
- "[verbatim quote]"
- **Positive Feedback:** [what the participant liked]
- **Pain Points:** [issues, confusion, or challenges observed]
## Insights & Opportunities
- **Key Insights:**
- [primary takeaway]
- **Opportunities for Improvement:**
- [potential improvement or new idea]
## Follow-Up Actions
- **Next Steps:**
- [follow-up interview, test, or design adjustment]
- **Additional Notes:** [extra observations or context]
Use to prepare a structured but flexible script for a user interview, ensuring key topics are covered without over-constraining the conversation.
<!--
template_type: interview_guide
project: [project_name]
status: [draft|in_progress|completed]
priority: [high|medium|low]
-->
# Interview Guide: [topic or research question]
- **Date:** [YYYY-MM-DD]
- **Interviewer:** [name or email]
- **Participant:** [name or pseudonym]
- **Goal:** [what you are trying to learn from this interview]
## Warm-up
- Tell me a bit about your role and day-to-day work.
- [custom warm-up question]
## Core questions
- [main question 1]
- [main question 2]
- [main question 3]
## Follow-up probes
- Can you tell me more about that?
- What happened next?
- Why did that matter to you?
- What would have made that easier?
## Wrap-up
- Is there anything else you'd like to share that we haven't covered?
- [any specific wrap-up question]
## Notes
- [observations, quotes, and anything worth capturing during the session]
Use to document the findings of a technical or conceptual exploration — an API spike, library evaluation, or any investigation done to inform a decision.
<!--
template_type: study
project: [project_name]
status: [draft|completed|archived]
priority: [high|medium|low]
-->
# Study: [subject]
- **Date:** [YYYY-MM-DD]
- **Author:** [name or email]
- **Goal:** [what question or decision this study was meant to answer]
- **Approach:** [how it was explored — reading docs, writing a spike, testing, etc.]
- **Key findings:**
- [finding]
- **Limitations & gotchas:**
- [caveat, constraint, or surprising behavior to be aware of]
- **Recommendations:**
- [what to do, use, avoid, or investigate further]
- **References:**
- [links to docs, code, articles, or related studies]
Use in a group workshop to generate and converge on a shared product vision through structured word association.
<!--
template_type: shared_vision_triads
project: [project_name]
status: [planning|workshop|completed]
priority: [high|medium|low]
-->
# Develop Shared Vision with Triads: [vision_session_name]
<!-- Source: The User Experience Team of One. Leah Buley and Joe Natoli. 2nd edition, p.124. -->
- **Step 1: Describe the product/service**
- [10+ words that describe the product or service]
- **Step 2: Pick words in groups of three**
- [word_triad_1]
- **Step 3: For each group — describe**
- **Related nouns (5-10):** [nouns that come to mind — system objects]
- **Related verbs (5-10):** [verbs that come to mind — system actions]
- **Related adjectives (5-10):** [adjectives that come to mind — look, feel, and behavior]
- **Step 4: For each outcome — describe what you see**
- **Experience vision:** [what kind of experience do you envision]
- **Important parts:** [most important parts of the product/service]
- **How it works:** [how the product/service works]
- **User feelings:** [how users and customers would feel]
Use to frame a specific user need as a job statement, including friction, success criteria, and open questions.
<!--
template_type: job_to_be_done
project: [project_name]
status: [research|analysis|validated|implemented]
priority: [high|medium|low]
-->
# Job to Be Done (JTBD): [jtbd_name]
- **Person:** [who is trying to accomplish this]
- **Job Statement:** [When I... I want to... so I can...]
- **Pain Points & Frictions:**
- [ ] [specific issue or friction]
- **Success Criteria:** [what success looks like]
- **Existing Alternatives / Workarounds:**
- [current workaround or alternative]
- **Proposed Solution (if applicable):** [brief description]
- **Open Questions / Risks:**
- [uncertainty or blocker]
Use to explore the why-chain above and the how-steps below a job statement, revealing higher-order motivations and concrete sub-tasks.
<!--
template_type: jtbd_hierarchy
project: [project_name]
status: [research|analysis|validated|implemented]
priority: [high|medium|low]
-->
# Job to Be Done (JTBD) Hierarchy: [jtbd_hierarchy_name]
- **Why:** [deeper motivation — repeat as needed]
- **Job Statement:** [When I... I want to... so I can...]
- **How:** [concrete step — repeat as needed]
## Example
- **Why:** To jumpstart my morning energy
- **Why:** To enjoy a comforting routine
- **Why:** To carve out a quiet moment for myself
- **Why:** To boost my productivity for the day
- **Job Statement:** When I start my day, I want to make myself a cup of coffee before leaving home.
- **How:** Boil water using a kettle
- **How:** Measure and grind coffee beans (or use a coffee pod)
- **How:** Brew the coffee with a coffee maker
- **How:** Pour the coffee into a mug
Use to document a usability or interaction problem found during testing or production, including reproduction steps and severity.
<!--
template_type: ux_issue
project: [project_name]
status: [reported|investigating|in_progress|resolved|closed]
priority: [critical|major|minor|trivial]
-->
# UX Issue: [issue_name]
- **Summary:** [short, clear description]
- **Description:** [steps to reproduce, detailed description]
- **Expected vs. Actual:**
- Expected: [what should happen]
- Actual: [what actually happens]
- **UI Elements Affected:**
- [affected component or screen]
- **Screenshots / Recordings:**
- 
- **Environment:**
- Device: [Desktop|Mobile|Tablet]
- OS: [Windows|macOS|Linux|iOS|Android]
- Browser: [Chrome|Firefox|Safari|Edge|Other]
- **Possible Solutions:**
- [potential solution]
- **Severity:** [Critical|Major|Minor|Trivial]
- **Reported by:** [email]
- **Date Reported:** [YYYY-MM-DD]
Use during ideation to reframe a problem or insight as an open-ended opportunity question.
<!--
template_type: hmw
project: [project_name]
status: [draft|active|completed]
priority: [high|medium|low]
-->
# How Might We (HMW): [hmw_name]
- **Challenge Area:** [broad problem space]
- **Observation / Insight:** [what we have learned]
- **How Might We:** HMW [action] for [user] so that [desired_outcome]?
- **Constraints / Considerations:** [limitations or factors to consider]
- **Related:** [links or references to related work]
Use to clearly define a problem before generating solutions, ensuring alignment on context, affected users, and desired outcome.
<!--
template_type: problem_statement
project: [project_name]
status: [draft|defined|validated|solved]
priority: [high|medium|low]
-->
# Problem Statement: [problem_statement_name]
- **Context:** [background of the issue]
- **Problem:** [what the issue is and why it matters]
- **Who is affected:** [user group or stakeholders]
- **Goal / Desired Outcome:** [what should be achieved]
- **Pain Points / Challenges:**
- [issue or challenge]
- **Supporting Data / Insights:** [research, analytics, evidence]
- **Potential Solutions (if applicable):** [suggested approaches]
Our [customer_segment] are [problem_what] because they [reason_why].
If we solve this, it would impact [customer_segment] positively by [customer_benefit] and benefit our business by [business_benefit].
Use when a problem feels stuck or bloated because multiple issues have become entangled. The goal is not to solve everything — it is to find what actually needs solving and take the simplest path to that.
The key move is to challenge each part before committing to solving it. A problem you can eliminate is better than a problem you solve well. Ask: what assumption is baked into this part? If you remove that assumption, does the problem disappear?
# Problem Simplification: [topic]
## The compound problem
[Describe the full problem as it appears right now — all tangled parts included.]
## Break it into parts
- **Part A:** [first distinct problem, constraint, or dependency]
- **Part B:** [second distinct problem, constraint, or dependency]
## Challenge each part
- **Part A:** [restate]
- What assumption is baked in? [what are we taking for granted about why this part exists?]
- Can we remove the need for this entirely, replace it, or defer it? [yes/no — how?]
- Decision: [solve | eliminate | replace | defer]
- **Part B:** [restate]
- What assumption is baked in?
- Can we remove the need for this entirely, replace it, or defer it?
- Decision: [solve | eliminate | replace | defer]
## What remains?
[After removing everything that can be eliminated, replaced, or deferred — what is the irreducible problem?]
## Simplest path forward
[What is the smallest next action that makes real progress on what remains?]
Use to guide a team through the four phases of design thinking: discover, define, develop, and deliver.
<!--
template_type: double_diamond
project: [project_name]
status: [discover|define|develop|deliver]
priority: [high|medium|low]
-->
# Double Diamond: [double_diamond_name]
- **Date:** [YYYY-MM-DD]
- **Participants:** [names/emails]
## Discover
- **Problem Exploration:** [understanding the challenge]
- **User Research:** [key insights]
- **Data Analysis:** [findings]
- **Challenges Identified:**
- [challenge]
## Define
- **Key Problem Statement:** [clear articulation]
- **Pain Points:**
- [pain point]
- **Scope & Constraints:** [in/out of scope]
## Develop
- **Brainstorming Ideas:**
- [idea]
- **Wireframes / Mockups:** [links or screenshots]
- **Prototype Testing:** [user feedback]
## Deliver
- **Final Solution:** [what was implemented]
- **Impact Measurement:** [metrics and feedback]
- **Iterative Improvements:** [next steps]
Use to map a user's steps, emotions, and pain points across a specific scenario or workflow.
<!--
template_type: user_journey
project: [project_name]
status: [draft|in_progress|validated|implemented]
priority: [high|medium|low]
-->
# User Journey: [user_journey_name]
- **Stages:** [e.g. "Detection → Reporting → Diagnostics → Repair → Validation"]
- **User Goals:** [what the user is trying to achieve]
- **Pain Points:** [obstacles or frustrations]
- **Opportunities:** [areas for improvement]
- **Randomness / Variability:** [factors that make the journey unpredictable]
- **Mapped Business Process:** [related business process]
- **Key Metrics:** [measures of success, e.g. "Reduce Mean Time to Repair"]
Use to create a reference profile of a key user type to ground design decisions in real user needs.
<!--
template_type: persona
project: [project_name]
status: [draft|validated|active|archived]
priority: [high|medium|low]
-->
# Persona: [persona_name]
- **Role:** [persona role]
- **Picture:** [photo or illustration]
- **Focus:** [key interaction aspect]
- **Notes:** [motivations, goals, challenges]
Use to describe a realistic situation in which a specific persona interacts with the product, anchoring design hypotheses in context.
<!--
template_type: contextual_use_scenario
project: [project_name]
status: [draft|validated|implemented|archived]
priority: [high|medium|low]
-->
# Contextual Use Scenario: [scenario_name]
- **ID:** [unique ID, e.g., "#001"]
- **Group:** [scenario group, e.g., "Diagnostics"]
- **Persona:** [related persona]
- **Description:** [narrative explanation]
- **User Goal:** [what the user is trying to achieve]
- **Design Hypothesis:** [early design ideas]
Use to express a user need from the user's perspective as input for development planning or backlog grooming.
<!--
template_type: user_story
project: [project_name]
status: [draft|reviewed|finalized|archived]
priority: [high|medium|low]
-->
# User Story: [story_name]
- **Role:** [user or stakeholder, e.g. "Maintenance Technician"]
- **Action / Need:** [what the user wants to do]
- **Purpose / Benefit:** [why it is needed]
- **Full User Story:** "As a [role], I want to [action] so that [benefit]."
- **Dependencies:** [tools or conditions required]
- **Outcome:** [success criteria]
Use to describe a specific interaction between a user and the system, including preconditions, steps, and expected outcomes.
<!--
template_type: use_case
project: [project_name]
status: [draft|defined|validated|implemented]
priority: [high|medium|low]
-->
# Use Case: [use_case_name]
- **Objective:** [purpose of the interaction]
- **Preconditions:** [what must be true before starting]
- **Steps:**
1. [first step]
2. [next step]
- **Outcome:** [expected result]
- **Pain Points:** [potential challenges]
- **Opportunities:** [potential improvements]
- **Dependencies:** [required tools or systems]
Use to document what changed in a design version, solicit targeted feedback, and plan the next iteration.
# Design Version Notes
- **Version:** [e.g., v1.0]
- **Date:** [YYYY-MM-DD]
- **Author:** [email]
- **Overview:** [brief description of this version and its focus]
- **Context:** [background and reasons for this version]
- **What is new?:**
- **Main reason for new version:** [how this version improves on past designs]
- **Change 1:** [description]
- **Known issues:**
- **Issue 1:** [description]
- **Concerns and uncertainties:** [reservations or open questions]
- **Feedback Requested From:** [stakeholders or team members]
- **Focus Areas for Feedback:**
- [ ] Interaction design
- [ ] Visual aesthetics
- [ ] Usability
- [ ] Alignment with brand guidelines / design system
- [ ] Functionality
- **How to Provide Feedback:** [e.g., comments in the document, email, or scheduled review meeting]
- **Planned Revisions:** [planned changes based on feedback]
- **Next Version Roadmap:** [what is planned for the next iteration]
- **Notes:** [extra information or references]
Use when planning a testing strategy to systematically cover all dimensions of an application: structure, function, data, interfaces, platform, operations, and time.
<!--
template_type: sfdipot
project: [project_name]
status: [analysis|in_progress|completed]
priority: [high|medium|low]
-->
# SFDIPOT: [sfdipot_analysis_name]
## Structure
- **Architecture:** [description of application architecture]
- **Technologies:** [databases, APIs, authentication methods, etc.]
- **Third-party dependencies:** [external services relied upon]
## Function
- **Key functionalities:** [list of key functionalities]
- **Critical user actions and system processes:** [critical paths]
- **Hidden or less obvious functions:** [non-obvious behaviors]
## Data
- **Data types:** [types of data handled]
- **Data handling:** [storage, processing, and transmission]
- **Validation checks:** [input validation methods]
## Interfaces
- **Application interfaces:** [UI, API, CLI, third-party integrations]
- **Import/export features:** [capabilities]
- **Error messages and logs:** [quality and clarity]
## Platform
- **Supported platforms:** [OS, browsers, mobile devices]
- **Platform-specific behaviors:** [known issues or differences]
- **System requirements:** [minimum requirements]
## Operations
- **Users and maintainers:** [who runs and maintains the system]
- **Security, logging, monitoring:** [considerations]
- **Backup and recovery:** [strategies]
## Time
- **Time-dependent functions:** [scheduling, time zones, expiration dates]
- **Date/time change handling:** [leap years, daylight saving, etc.]
- **Performance under peak loads:** [considerations]
Use to run a structured session for identifying and prioritizing the metrics that best reflect the user experience goals of a product.
<!--
template_type: ux_kpi_discovery
project: [project_name]
status: [discovery|analysis|defined|implemented]
priority: [high|medium|low]
-->
# UX KPI Discovery: [kpi_discovery_name]
## Define UX Objectives & Goals
- **Objective Statement:** [overall UX vision or mission]
- **Key UX Challenges:** [main challenges users face]
- **Desired Outcomes:** [improvements or successes aimed for]
## Analyze the User Journey & Critical Touchpoints
- **User Journey Mapping:** [key steps and interactions]
- **Critical Moments:** [touchpoints with the most impact on satisfaction]
## Brainstorm Potential Metrics
- **What Does Success Look Like?** [qualitative and quantitative indicators]
- **Potential KPI Ideas:**
- [ ] **KPI Idea 1:** [description and rationale]
- **User Feedback Integration:** [how user feedback informs metric selection]
## Data Availability & Measurement Feasibility
- **Data Sources:** [analytics tools, surveys, usability tests, etc.]
- **Measurement Capabilities:** [what is tracked and what could be added]
- **Feasibility Considerations:** [limitations or technical constraints]
## Define Selection Criteria for KPIs
- **Relevance:** [how directly does the KPI address UX objectives?]
- **Actionability:** [will this KPI drive actionable improvements?]
- **Simplicity & Clarity:** [is it easy to understand across teams?]
- **Timeliness:** [how frequently can it be measured and reviewed?]
## Prioritize & Refine KPIs
- **Evaluation of Potential KPIs:** [rate each KPI idea against the criteria above]
- **Final Selection:** [KPIs that best align with UX objectives]
- **Next Steps for Implementation:** [plan for tracking, reviewing, and refining]
## Additional Notes & Insights
- **Insights & Observations:** [discoveries from the process]
- **Action Items:** [assigned responsibilities for further research or implementation]
Use to generate solutions indirectly by first listing ways to worsen the problem, then reversing each idea.
<!--
template_type: reverse_brainstorm
project: [project_name]
status: [planning|in_progress|completed]
priority: [high|medium|low]
-->
# Reverse Brainstorm: [reverse_brainstorm_name]
- **Problem Statement:** [challenge or issue to address]
- **Negative Ideation:** [ideas on how to worsen the problem]
- **Reversal Strategies:** [for each negative idea, how doing the opposite could offer a solution]
- **Potential Solutions:** [actionable solutions based on the reversed ideas]
- **Evaluation:** [feasibility, impact, and potential risks]
- **Next Steps:** [action items, responsibilities, and deadlines]
Use to break out of conventional framing by mapping the problem onto an unrelated metaphor and drawing insights from that mapping.
<!--
template_type: metaphoric_thinking
project: [project_name]
status: [exploration|analysis|insights_captured]
priority: [high|medium|low]
-->
# Metaphoric Thinking: [metaphoric_thinking_name]
- **Concept / Challenge:** [idea or problem to explore]
- **Selected Metaphor:** [metaphor that represents the situation, e.g., "a garden in need of nurturing"]
- **Metaphor Breakdown:**
- **Components:** [elements of the metaphor and their real-life counterparts]
- **Mapping:** [how the metaphor relates to the actual challenge]
- **Insights & Implications:** [new perspectives derived from the metaphor]
- **Action Items:** [steps inspired by these insights]
Use in team or personal development sessions to surface blind spots, build self-awareness, and open conversations about perception gaps.
# Johari Window: [name]
<!-- Subject selects adjectives that describe themselves; others select adjectives they associate with the subject. Overlap → Open; subject-only → Facade; others-only → Blind Spot; neither → Unknown. -->
- **Open/Arena** (known to self, known to others):
- [traits, behaviors, or information openly shared]
- **Blind Spot** (unknown to self, known to others):
- [traits others observe that the subject is unaware of]
- **Facade** (known to self, unknown to others):
- [traits or information the subject knows but keeps private]
- **Unknown** (unknown to self, unknown to others):
- [undiscovered potential, latent traits, or unexplored areas]
Use at the end of planning, before work begins, to proactively surface failure modes by imagining the project has already failed.
<!--
template_type: pre_mortem
project: [project_name]
status: [planning|completed]
priority: [high|medium|low]
-->
# Pre-mortem: [project_name]
<!-- Imagine it is [date] and the project has failed. Work backwards to identify what went wrong. -->
- **Imagined failure scenario:** [brief description of how the project failed]
- **Assumed failure date:** [YYYY-MM-DD]
- **Causes of failure:**
- [what went wrong]
- **Early warning signs:** [signals that would have indicated trouble before it was too late]
- **Preventive actions:**
- [action to take now to prevent this cause]
Use during meetings, reading, or research sessions to capture context, surface questions, collect evidence, and distill takeaways.
<!--
template_type: note_taking_cqeidt
project: [project_name]
status: [active|completed|archived]
priority: [high|medium|low]
-->
# Note-taking C-Q-E/I/D-T: [note_session_name]
- Context:
- [background information and foundational details that set the stage]
- Questions:
- [key questions that arise or need to be explored]
- Evidence / Ideas / Discussion:
- [facts, insights, arguments, and discussion]
- Takeaways:
- [final summary or conclusion]
Use to define how, when, and to whom project information will be communicated throughout an initiative.
<!--
template_type: communication_plan
project: [project_name]
status: [draft|active|completed]
priority: [high|medium|low]
-->
# Communication Plan: [communication_plan_name]
- **Objective:** [purpose of the communication plan]
- **Audience:** [stakeholder groups]
- **Channels:** [email, meetings, Slack, Teams, etc.]
- **Frequency:** [how often communications occur]
- **Responsible:** [person's email]
Use after a meeting to record decisions, action items, and next steps for participants and stakeholders who were absent.
<!--
template_type: meeting_memo
project: [project_name]
status: [draft|finalized|archived]
priority: [high|medium|low]
-->
# Meeting Memo: [meeting_memo_name]
- **Date/Time:** [YYYY-MM-DD HH:MM-HH:MM]
- **Location / Link:** [meeting room or video call link]
- **Attendees:** [names/emails]
- **Agenda:**
1. [agenda topic]
- **Key Notes & Discussions:**
- [key point discussed]
- [question raised]
- **Decisions Made:**
- [decision]
- **APs:**
- [ ] [action_owner] [action_description]
- **Next:** [next steps or follow-up]
- **Attachments & References:** [link or file]
Use to report project progress to stakeholders or a team at the end of each week: what happened, what was found, what is next.
<!--
template_type: weekly_summary
project: [project_name]
status: [draft|sent]
priority: [high|medium|low]
-->
# Weekly Summary: [project_name] — Week of [YYYY-MM-DD]
- **Highlights:**
- [most important thing that happened this week]
- **Work completed:**
- [deliverable or task finished]
- **In progress:**
- [ongoing work and current state]
- **Findings & learnings:**
- [discovery, insight, or data point worth sharing]
- **Blockers:**
- [what is slowing things down and who needs to act]
- **Decisions made:**
- [decision and rationale]
- **Next week:**
- [planned work or focus for the coming week]
Use before a meeting to share the schedule, expected outcomes, and any preparation required from attendees.
<!--
template_type: meeting_agenda
project: [project_name]
status: [draft|final|completed]
priority: [high|medium|low]
-->
# Meeting Agenda: [meeting_agenda_name]
- **Date/Time:** [YYYY-MM-DD HH:MM]
- **Location / Link:** [meeting room or video call link]
- **Agenda:**
1. [agenda topic]
- **Expected Outcomes:** [what is to be achieved]
Use to document an architectural or strategic decision, the context behind it, the alternatives considered, and the expected consequences.
<!--
template_type: decision_record
project: [project_name]
status: [draft|proposed|accepted|deprecated]
priority: [high|medium|low]
-->
# Decision Record: [decision_record_name]
- **ID:** [unique ID]
- **Date:** [YYYY-MM-DD]
- **Author(s):** [email]
- **Status:** [Draft|Proposed|Accepted|Deprecated]
- **Context:** [problem and constraints]
- **Decision:** [chosen solution and rationale]
- **Alternatives:**
1. **[alternative_1]** — [pros/cons]
- **Consequences:** [implications of the decision]
- **Next Steps:**
- [follow-up action] [YYYY-MM-DD]
Use to quickly weigh a decision or option by listing advantages and disadvantages side by side.
# Pros and Cons
- **Topic / Decision:** [what is being evaluated]
- **Date:** [YYYY-MM-DD]
- **Evaluated by:** [email]
## Pros
| Advantage | Explanation |
| --------- | --------------------- |
| [Pro 1] | [Why it's beneficial] |
## Cons
| Disadvantage | Explanation |
| ------------ | --------------------- |
| [Con 1] | [Why it's a drawback] |
## Final Thoughts
[Summary of key takeaways]
Use to document an unresolved disagreement between parties, capture multiple perspectives, and identify barriers to resolution.
# Conflict: [Conflict Name]
- **Summary:** [brief explanation]
- **Context:** [background leading to the conflict]
- **Involved Parties:**
| Role | Name | Perspective |
| ------ | ------ | ---------------------- |
| [Role] | [Name] | [Viewpoint or concern] |
- **Key Issues:**
- [point of contention]
- **Points of Disagreement:**
- **Perspective 1:** [one side's stance]
- **Perspective 2:** [opposing stance]
- **Impact:** [how it affects the project/team]
- **Constraints & External Factors:** [influencing factors]
- **Attempts to Address:** [mitigation steps]
- **Barriers to Resolution:** [factors preventing resolution]
- **Urgency:** [time constraints]
- **Additional Notes:** [extra context]
Use to surface and track implicit assumptions in a project, assess their risk if wrong, and plan how to validate them.
<!--
template_type: assumption
project: [project_name]
status: [identified|validated|invalidated|archived]
priority: [high|medium|low]
-->
# Assumption: [assumption_name]
- **Statement:** "[exact quote or summary]"
- **Inferred Assumption(s):**
- [ ] **Assumption:** [underlying assumption implied by the statement]
- **Key Phrases:** [phrases that suggest the assumption]
- **Potential Impact if False:** [risks or outcomes if the assumption does not hold]
- **Follow-Up / Clarification:**
- **Question:** [e.g., "Can you explain what data supports this view?"]
- **Action Item:** [responsible person and due date]
Use before starting a test cycle to define what is being tested, how, and what counts as done.
<!--
template_type: test_plan
project: [project_name]
status: [draft|active|completed]
priority: [high|medium|low]
-->
# Test Plan: [feature or scope]
- **Goal:** [what is being validated]
- **Scope:**
- In: [what will be tested]
- Out: [what will not be tested]
- **Approach:** [manual|automated|exploratory|combination — and how]
- **Environment:** [browser, device, OS, test data, dependencies]
- **Test items:**
- [thing to test]
- **Exit criteria:** [what "done testing" looks like]
- **Risks:** [areas of uncertainty or known gaps in coverage]
Use to track the pass/fail status of individual test cases during a test cycle.
# Test Tracker: [feature or scope]
| # | Test Item | Status | Notes |
| - | --------- | ------ | ----- |
| 1 | [what is being tested] | ⬜ | |
Legend: ✅ Pass ❌ Fail 🔄 In progress ⏭️ Skipped ⬜ Not started
Use to monitor the overall status, timeline, deliverables, and risks of a work track or workstream.
<!--
template_type: track
project: [project_name]
status: [not_started|in_progress|completed|pending|skipped|postponed]
priority: [high|medium|low]
-->
# Track: [track_name]
- **Current Status:** [Not started|In Progress|Completed|Pending|Skipped|Postponed]
- **Description:** [overview of the track]
- **Goals & Objectives:** [what the track aims to achieve]
- **Timeline:**
- Start: [YYYY-MM-DD]
- Estimated Completion: [YYYY-MM-DD]
- **Key Deliverables:**
- [ ] **[deliverable_1]** — Due: [YYYY-MM-DD]
- **Dependencies:** [dependencies or links, including RACI if applicable]
- **Risks & Challenges:** [potential blockers]
- **Success Metrics:** [how success is measured]
Use to clarify roles and responsibilities across tasks or deliverables for a project or initiative.
<!--
template_type: raci
project: [project_name]
status: [draft|active|completed|archived]
priority: [high|medium|low]
-->
# RACI: [raci_name]
**Description:** [overview of roles and responsibilities]
## RACI Definitions
| Letter | Meaning | Description |
| ------ | ----------- | ------------------------ |
| **R** | Responsible | Does the work |
| **A** | Accountable | Makes the final decision |
| **C** | Consulted | Provides input |
| **I** | Informed | Kept updated |
## Roles & Responsibilities
| Task / Deliverable | Responsible (R) | Accountable (A) | Consulted (C) | Informed (I) |
| ------------------ | --------------- | --------------- | ------------- | ------------ |
| **[Task 1]** | [Name/Role] | [Name/Role] | [Name/Role] | [Name/Role] |
Use to decompose a project into phases and tasks, giving the team a shared map of all work to be done.
<!--
template_type: wbs
project: [project_name]
status: [planning|active|completed|archived]
priority: [high|medium|low]
-->
# Work Breakdown Structure (WBS): [wbs_name]
- **Tasks Breakdown:**
1. **Phase 1:**
- Task 1: [description]
2. **Phase 2:**
- Task 1: [description]
- **Milestones:** [key milestones]
Use to identify, assess, and track project risks along with their mitigation strategies and owners.
<!--
template_type: risk_register
project: [project_name]
status: [active|under_review|closed]
priority: [high|medium|low]
-->
# Risk Register: [risk_register_name]
| Risk ID | Description | Impact (High/Med/Low) | Probability (High/Med/Low) | Mitigation Plan | Owner |
| ------- | ------------- | --------------------- | -------------------------- | --------------------- | ----------- |
| R-001 | [Risk Detail] | High | Medium | [mitigation strategy] | [Name/Team] |
- **Risk Monitoring Plan:** [how risks will be reviewed]
Use to formally propose a scope, timeline, or budget change and track its approval and impact.
<!--
template_type: change_request
project: [project_name]
status: [pending|approved|rejected|implemented]
priority: [high|medium|low]
-->
# Change Request: [change_request_name]
- **Date:** [YYYY-MM-DD]
- **Change Title:** [brief description]
- **Reason for Change:** [why the change is needed]
- **Impact Assessment:**
- Timeline: [Increase|Decrease|No impact]
- Budget: [Increase|Decrease|No impact]
- Resources: [More|Less|Same]
- **Approval Status:** [Pending|Approved|Rejected]
- **Stakeholders Notified:** [affected teams]
- **Next Steps:** [implementation plan if approved]
Use after a sprint, project phase, or incident to capture what worked, what didn't, and what the team commits to changing.
<!--
template_type: retrospective_summary
project: [project_name]
status: [conducted|documented|actions_assigned]
priority: [high|medium|low]
-->
# Retrospective Summary: [retrospective_name]
- **Topic/Scope:** [time period, sprint, or project]
- **Date:** [YYYY-MM-DD]
- **What Went Well:** [key successes]
- **Challenges Faced:** [obstacles encountered]
- **Actionable Improvements:** [improvements and owners]
- **Next Steps:** [agreed actions for the next period]
Use to summarize a new feature — its purpose, expected impact, and key components — before detailed planning begins.
<!--
template_type: feature_brief
project: [project_name]
status: [concept|planning|in_development|completed]
priority: [high|medium|low]
-->
# Feature Brief: [feature_name]
- **Summary:** [brief overview]
- **Purpose:** [why this feature is needed]
- **Impact:** [expected benefits]
- **Key Components:**
- [component]
Use to define the conditions a feature or task must meet before it is considered done.
<!--
template_type: acceptance_criteria
project: [project_name]
status: [draft|reviewed|approved|validated]
priority: [high|medium|low]
-->
# Acceptance Criteria: [acceptance_criteria_name]
- **Feature/Task:** [feature or task name]
- **Criteria:**
- [ ] Criterion 1: [description]
- **Validation:** [how criteria will be verified]
Use when writing a development task ticket to give engineers full context on the goal, reasoning, design decisions, and success criteria.
<!--
template_type: dev_task_description
project: [project_name]
status: [planning|in_progress|code_review|testing|completed]
priority: [high|medium|low]
-->
# Dev Task Description: [dev_task_name]
- **Title:** [short, descriptive title]
- **Objective:** [goal and problem being solved]
- **Context:** [background and current situation]
- **Why This Task:** [reasoning and expected benefits]
- **Impact:** [expected outcomes or changes]
- **Description:** [functionality or changes to implement, key requirements and constraints]
- **Design Considerations:** [technical or design decisions and why they were chosen]
- **Other Approaches:** [alternatives considered and why they were not selected]
- **Result:** [what successful completion looks like]
- **Notes:** [extra insights, references, or considerations]
Use to triage a backlog or scope a release by sorting items into hard commitments, strong intentions, nice-to-haves, and explicit non-starters.
# MoSCoW: [topic or release name]
## Must
- [ ] [item that is non-negotiable for this scope]
## Should
- [ ] [item that is highly valuable but not a blocker]
## Could
- [ ] [item to include only if time and resources allow]
## Won't
- [item explicitly out of scope for now]
Use to triage a mixed pile of tasks into buckets by urgency and intent — including a place to park dropped items and ideas without losing them.
# Task Group: [topic]
## Urgent and important
- [ ] [task]
## Not time critical, but must be done
- [ ] [task]
## Should probably be done at some point
- [ ] [task]
## Dropped
- [task]
## Ideas
- [task]
Use for a quick at-a-glance view of where a set of items stands and what the immediate next action is for each.
# Progress: [topic]
| Item | Status | Next |
| ---- | ------ | ---- |
| [item] | [not started\|in progress\|done\|blocked] | [next action] |