| name | design-gtd-system |
| description | Use when your personal productivity system feels unreliable, tasks are falling through cracks, or you are starting from scratch with a trusted external system |
| source | David Allen, "Getting Things Done" (2001, revised 2015); adopted at Google, NASA, US military |
| tags | ["gtd","task-management","productivity-system","capture","organisation","trusted-system"] |
| verified | true |
Design GTD System
Build a personal productivity system using GTD's five stages — Capture, Clarify, Organise, Reflect, Engage — so the mind is free to work rather than remember.
Why This Is Best Practice
Adopted by: Google, NASA, US military leadership programs, major consulting firms; GTD is the most widely implemented personal productivity system in knowledge work
Impact: Allen: the mind is for having ideas, not holding them — every open loop held in memory consumes cognitive resources; externalising to a trusted system produces measurable reductions in stress and increases in creative throughput
Why best: GTD works because it addresses the root cause of overwhelm: incomplete agreements with yourself. Each uncaptured task is an open loop draining background attention. The system closes loops by placing every commitment in a defined location with a defined next action, making it possible to engage with the present without anxiety about what might be forgotten.
Steps
- Set up one capture inbox — One physical tray and one digital inbox (email, notes app, or dedicated capture tool); everything new enters here, nothing else
- Clarify daily — Process every inbox item to a decision: Is it actionable? If no: trash, someday/maybe list, or reference archive. If yes: proceed
- Define the next physical action — For every actionable item, write the next visible, physical action (not a project name; a verb + object: "call Sarah to confirm budget")
- Organise into context lists — Group next actions by context: @computer, @phone, @errands, @waiting-for; assign projects to a project list
- Build a project list — Every outcome requiring more than one action is a project; every project needs at least one next action on a context list at all times
- Run the weekly review — Every week: process all inboxes, review all projects, verify next actions, review calendar and someday/maybe list
- Engage by context — When working, choose from your context list based on location, time available, energy level, and priority — not from memory
Rules
- Nothing stays in the inbox — process to a decision, not to "I'll think about this later"
- Every project must have at least one next action; a project without a next action is stalled and creates anxiety
- Capture inboxes must be reviewed to zero at least once per day; an inbox that is never emptied is not a system, it is a pile
- "Next action" must be physical and visible — "think about the proposal" is not a next action; "open Word doc and write outline header" is
- Never use the inbox as storage — it is a temporary holding zone, not a reference system
Examples
Capture: Meeting note says "sort out the server issue" → into inbox
Clarify: Is it actionable? Yes → next action: "email DevOps team asking for AWS cost report by Friday"
Organise: Added to @computer list; "Server migration" added to project list
Engage: At desk with 30 minutes before next meeting → scan @computer list → find "email DevOps team" → do it
Common Mistakes
- Using the inbox as a to-do list — Items sit unprocessed; the inbox becomes a source of anxiety rather than a processing queue
- Project names as next actions — "Website redesign" on a context list is not a next action; it provides no guidance on what to physically do next
- Skipping the weekly review — The system degrades within 5–7 days without a review; open loops return to memory and overwhelm returns
- Too many capture points — Multiple inboxes (physical, email, 3 apps, Slack) create a system you don't trust; consolidate to the fewest viable capture points
