With versions available for both iOS and OS X, OmniFocus is the most powerful task management system intended for individuals on the Apple platform. OmniFocus is highly configurable, allowing the user to tailor it to their own particular approach to GTD (Getting Things Done). Until recently, I’ve struggled with identifying an ideal approach to using OmniFocus for task management. The solution I settled on is described in this post.
The core GTD principles
The first principle of GTD is capture—i.e. getting things out of your head and into a place you can rely on to keep them safe while they wait for later processing. This principle applies equally to everyone.
A second principle of GTD is the separation of tasks by context, and it is here where much of the discussion regarding various approaches to GTD is (rightfully) focused. Some people contextualize their tasks around physical energy levels (high, low), some around where tasks can be done (home, office, computer, on the phone) and some around task nature (work, personal, errands). I’ve experimented with all of these, and ultimately they all fell short.
My task management objectives
The problem starts with capture. Since the objective of capture is keeping your head clear, the process results in my inbox containing two types of tasks—those I will do, and those I might do.
Of course there are other dimensions in which you could classify those tasks, but over time, I’ve discovered that the effective separation of these two has the most impact, for me, in making GTD actually work.
The challenge then has been identifying a GTD approach that:
- Shows me what I will do, without cluttering that view with things I might do.
- Allows me at any time to see the things I might want to do, and within the context of a particular project.
- Ensures that I’m periodically reminded of the things I might want to do.
To achieve those objectives, here are the tools provided by OmniFocus which affect the visibility of tasks.
- Perspectives, OmniFocus’s configurable task views, determine task visibility primarily through the “Availability” settings—“Available” or “Remaining”. (Perspectives can also filter on due dates; but due dates aren’t really relevant to whether a task will or might get done, as usually a task with a due date is something that will get done.)
- A Project’s status can be set to “Active”, in which case its tasks will be visible in both “Available” and “Remaining” perspective filters, or “On Hold”, in which case its tasks will only be visible when filtered on “Remaining”.
- A Context’s status can also be set to “Active” or “On Hold”, with the same affect on visibility in perspective filters.
- A “Defer” date can be assigned to a task. If that date is in the future, then the task will only appear in the “Remaining” perspective filter, and not when filtered on “Available”.
In the past, I tried to contextualize my tasks into “Work” and “Personal”, and then separate what I will and might do through the activity setting available to projects, e.g. using an on-hold project called, “Someday/Maybe”. The problem with that approach was that that single project contained tasks relevant to a variety of other “real” projects, which made it difficult to achieve my second objective—allowing me to see what I might want to do—within the context of a particular project.
So I tried to address that problem by creating on-hold “Someday/Maybe” child projects within each of my real active projects. But as you can imagine, that became unwieldy and maintenance-heavy once the number of real projects grew to any sizable amount.
I also tried creating an on-hold context called “Someday/Maybe” as a child context within each of my “Personal” and “Work” contexts, but eventually came to realize even that resulted in too much confusion and complexity in both initial context assignment, and when needing to change a given task—or group of tasks—from things I might do to things I will do.
I tried several other approaches as well and the result was always the same—either through over-complexity or incompatibility with my three objectives, OmniFocus wasn’t effectively helping me to get things done.
Realizing that in practice I didn’t actually view my tasks by “Work” and “Personal” contexts very often, even though I had organized them that way, I decided to try a simpler approach, consisting of only two contexts, the purpose of which is to answer the question, “Is this something I will do, or something I might do?”:
- “Active” (with status, Active)
- “Maybe” (with status, On Hold)
Now, when processing, organizing and managing tasks, I ask myself only two questions:
- What project should this belong to? (Project assignment)
- Is this something I will do, or might do? (Context assignment)
Here’s how that simplification fits into the core of my GTD approach.
Weekly review process:
- Each Sunday, I use OmniFocus’s “Review” feature to review each of my projects. When reviewing a project, OmniFocus shows you all of its tasks, regardless of availability. This satisfies my third objective, i.e. making sure I’m periodically reminded of the tasks I might do.
- I may change the context of some tasks from “Maybe” to “Active”, if I’ve decided they will get done.
- I “flag” any “Active” task I want to work on during the following week.
- I’ll assign a future “Defer” date to any task that is “Active”, but which I know I won’t get to in the near future. For example, the task “Follow up with Steve”, if I know Steve is on vacation for the next two weeks. (This supports my first objective, seeing only those tasks which are currently relevant.)
I have three core custom perspectives in OmniFocus which I access on a daily basis:
- “Active”—shows flagged and due tasks. This is what I look at to determine what to work on, today. This supports my first objective, i.e. quickly seeing just those things I’ve decided I will work on.
- “Worklist”—shows all “available” tasks, grouped by project. This is my global list of stuff I’ve decided I will do, without the noise of what I might do, and therefore also supports my first objective.
- “Maybe”—that shows all “remaining” tasks, grouped by project. This supports my second objective, i.e. at any time being able to see the tasks I might want to do, in the context of their relevant projects.
This approach to GTD and OmniFocus has resulted, for me, in a task management approach that is powerful enough to meet my objectives while remaining simple and efficient enough that I actually follow it consistently—and results in the feeling that OmniFocus helps me to be more productive.
Someone in the comments asked to see details of how the custom Perspectives are defined. Here they are:
- 2015-12-02 Tyler Hall (maker of VirtualHostX) extended my method with one additional context, “must do”, in order to add an element of timeliness and urgency. I can sympathize that, but I’m afraid that if I tried that approach, I’d end up experiencing friction between the use of that context and “will do”. It’ll be interesting to see how Tyler gets along in his adaptation!