I’m a lucky guy. I have a wife of almost twelve years, three kids, a home, a car, and a job where I have the opportunity to serve client needs and support my team with strategic guidance and enablers. The major cost of this great fortune is that I have many commitments, projects, and actions to manage. So, just like you, I’m busy.

It was in 2005 that I was first recommended Getting Things Done (GTD) after my cries for help as I surpassed the two hundred emails a day threshold for a sustained period of time. I’d just gotten a work promotion I may or may not have been ready for, and we were knee deep in planning all the aspects of our wedding. Life was moving at a furious pace, but GTD changed everything.

I loved the paper system I developed and carried with me religiously (I also think that it’s one of the easiest ways to learn the first principles of GTD), but it was later that same year that I got my first Mac, a 17” MacBook Pro, which came bundled with OmniOutliner. The internet steered me to Kinkless GTD, a set of Applescripts for OmniOutliner, and I was all in from there, following that solution’s maturation into OmniFocus.

Over time, I have come to respect and utilize OmniFocus in three very distinct ways, looking at it through three very different lenses, and I’m really excited to share that perspective (ha) here as part of sharing my workflow and how it is adopting the exciting new features in OmniFocus 3.

These three different ways of looking at OmniFocus map to the five steps of GTD workflow, if GTD is your bag, but can also be thought of in isolation of that if it isn’t. I might ebb and flow in and out of these different roles for OmniFocus rapidly, too, but each way of using or looking at OmniFocus has distinct purposes, and guides how I use features and approach the tool. Each has very different intended outcomes in application, and each serves a different purpose to enable my productivity.

These three dimensions are:

1. Knowing
2. Planning
3. Doing

OmniFocus for Knowing

I first treat OmniFocus as my external brain. That means it has to know and store all the things. Commitments, projects, actions, opportunities, and options must all be fully captured, clarified, and organized.

Before I can do things, or even plan what I will do, I need to have a complete inventory to draw from. In this respect, OmniFocus serves as a database of all the things in my life.

When I think about OmniFocus for knowing, I employ these key elements of the software:

• the inbox for quick capture of my ideas and stuff
• inroads to OmniFocus, such as Siri, Workflow workflows (I write a lot in iA Writer, share extensions (I often catch ideas in MindNode and OmniOutliner)
• the Review Perspective for looking at projects one at a time to consider if I have all the actions captured

I also employ organizational hierarchy to not only house my projects and actions, but also to trigger my thinking, ensuring everything I’ve had on my mind gets drawn in to OmniFocus.

Specifically, I have folders and single action list projects that group and trigger things I need to think about regularly:

Folders for Parallel and Sequential Projects (Outcomes)

• Work Projects for Clients
• Enablement Work Projects
• Other Professional Projects
• Personal Projects

Folders and their Single Action List Projects (Areas of Responsibility)

• Work Domains
  • My team
  • Tools/budget
  • Support
  • Consulting
  • Networking
  • Learning/Development
  • Admin
• My Domains
  • Spouse
  • Kids
  • Home and Household
  • Car
  • Finances
  • Friends and Family
  • Curiosities
• Checklists
  • Gifts
  • Activity ideas
  • Books to read
  • Music, movies, media
  • Food and drinks to try

This architecture supports my capture of everything by dividing projects into three kinds: outcomes (held in the first four folders noted above), areas of responsibility (the Domains folders with single action lists), and possibilities (the Checklists folder, where everything is pretty much on hold as an option for future consideration). This helps me think about what I need to do next to progress towards my outcomes, or do I have any things I need to do about aspects of my life that I am committed to managing.

Overall, when I am using OmniFocus for knowing, I am most concerned with having stuff captured, and am not sweating project states or defer dates or even tags a whole lot. The key outcome of this role of OmniFocus is building up an inventory of all the things first. I can assess what they mean through planning.

OmniFocus for Planning

Having solved a total database of all my things, the next step is to take that database and pare it down to reasonable options I want to have in front of me as choices for when I am doing.

In GTD, this is done through the Review/Reflect phase. GTD or not, though, I have found it crucial to look at OmniFocus this way from a mindset of planning, and not one of doing. With hundreds of projects/commitments captured, and an order of magnitude more actions associated to those, I simply can’t have all of that in my face when I’m in midst of my active day. In my tactical doing, I need to be looking only at the subset of that database that is most meaningful, important, or time-sensitive, so planning is needed to create that subset.

Since doing (which I’ll get to) will only examine available actions in OmniFocus, the key outcomes of planning is take as many things as I can out of an available status, and to have anything left in the available status as organized, defined, and categorized as possible so that doing is just doing (once I get to it).

There are several key elements of OmniFocus that I consider for this phase of work.

Project Statuses

The easiest way to take things out of being available is to use project statuses to either make projects on hold if I’m not going to look at them now, or drop them if I’m not actually going to commit to the project at all. Project relevance, meaning, and value can change over time, so I often flip projects in and out of these statuses, depending on what I might most want to work on.

Defer Dates

Defer dates mean that a particular project or action is unavailable until a prescribed time. It doesn’t mean I have to start the thing at that time, it just means that it’s off my list of options until then.

I do this a lot, both because some things can’t be started until a particular time, but also because I will arbitrarily decide that I don’t want many options in front of me when I go to my lists for doing, and so need to push out the less important, less urgent, or less meaningful work in favour of the better choices.

Tags

One of the huge new features of OmniFocus 3 is multiple tags. Where OmniFocus 2 allowed only one context (a limiter for what tasks could/could not be done based on time, tool, location, or other constraint), OmniFocus 3 allows me to assign multiple tags.

At first, I thought this mostly meant multiple contexts, or multiple conditions under which an action could be done, but I am finding that tags can also have categorical meaning, which is very valuable for planning.

I still have context-oriented tasks that help more with doing, but for planning, I am also using tags as ways to look at a group of actions to assess their meaning and do ability as a collective.

Some examples of these tags are:

• Sprint: My team works in agile two week sprints, so I tag all the actions I want done in the current sprint, allowing me to look at them together and make sure the sprint does not seem under- or over-subscribed.
• On Deck: Like above, but as a means of flagging the potentially most interesting things for the next sprint.
• Trip: I don’t work travel often, but when I do, it’s valuable to see all the actions I want to accomplish during a work trip, regardless of the projects they belong to or contexts they would be best accomplished in.
• Plan: These are actions that, because of complexity and time required, would benefit from being specifically time-planned for (i.e. put them on the calendar). I don’t want to use fake due dates, but I do want to deliberately think about when I would make them happen.

I can also use tags with an on hold status (such as my Someday/Maybe tag) to accomplish a similar effect to project statuses (above), as well as tags with defined locations so that I can split out work choices from when I’m at my desk and thinking, “What’s next?” from choices that require me to be out across various locations.

Due Dates

These I use very sparingly, but are important tools to make sure I hit deadlines. For me to assign a due date to something, it has to have meaning to someone other than me, and has to create a penalty for me if a due date would be missed.

If those criteria are met, however, due dates at project and action levels help prioritize the right kind of work at the right kind of times.

Flags

These I used very differently in OmniFocus 2, but in OmniFocus 3, I use flags to denote my “big three.” Each week, I choose three projects which, based on value, importance, urgency, or interest are my three most important projects, and I flag them.

By flagging the projects, their child actions become flagged, and so I can see at a glance (assuming those actions are available) which actions in my lists are related to my most important outcomes, and can look at doing them accordingly.

I go through this planning process weekly, with the intent of bringing my lists of hundreds of projects down to dozens (or fewer). Realistically, there is only so much time in the week, and so I need to make the hard choices about how that time will be spent (leaving room for all the unexpected stuff I can’t plan for, too).

I might also note that just because I mark something on hold or deferred doesn’t necessarily mean I won’t work on something about that project; it simply means that when I look to OmniFocus for options about what I do next, I don’t need those choices presented to me. I’m not pre-deciding a hard no on things that come up if things arise.

OmniFocus for Doing

This seems incredibly obvious, I suppose, since OmniFocus is a task manager after all, but I think distinguishing this dimension of its use from the other two helps clarify those other two roles.

In this application of OmniFocus, the goal is to check circles. To accomplish. And in order to do that, it is necessary that I have gone through the previous two dimensions, and then built perspectives that will enable me to further pare down the database to scannable lists of options.

I use several perspectives to help me do, and I’ve detailed them here.

Forecast

The updated Forecast perspective is amazing, as it shows me my due actions, as well as calendar things for today (if I like), and, to my delight, any actions tagged with the Forecast Tag.

Usually, my Today tag is shown there, and I can swipe to assign that tag to actions in other perspectives. This perspective serves as my home base for a day’s activity, and I make it my commitment to empty this perspective every day (either through completion or renegotiation of commitment, and untangling or deferral of actions).

Next

This is my foundation for doing. I use this perspective to show me all my available next actions, minus those that require specific conditions of other people, meetings, or locations. In other words, assuming I have a device that I can look at OmniFocus 3 on, what else could I do?

Looking at this perspective, I can swipe to assign the Forecast Tag to populate the Forecast perspective with today’s actions, or also make game time decisions about what else could be deferred, needs a due date, better tagging, etc.

Hotlist

Much like Next, this is a menu of choices for doing, except that it shows my flagged “big three” projects and their actions. I prefer this over the stock Flagged perspective, simply because I can use the presentation of grouping and sorting by entire project (which makes sense here, because I am looking at things from the point of view of relating to flagged projects).

Tags

Because I can tag actions in multiple ways, I often find that the built-in Tags perspective offers me a lot of what I need: a list of things that match a particular criteria (especially since the same action could show up in multiple lists).

Added (Available)

I appropriated this perspective idea from Merlin Mann on an episode of the Back to Work podcast. It shows available actions, but grouped and sorted by when they were added, the most recent at the top. It’s funny how often the most recent thing I’ve added is the thing I need to pick up and refer back to next.

Changed

Similar to Added Available, this shows everything but grouped and sorted on when last changes occurred. This lets me correct bad edits or changes, or quickly refer back to things I completed or updated recently.

Errands

Because my iPad doesn’t have the Nearby stock perspective, I built Errands to effectively group all my location-based tags that need me to be in particular locations to accomplish.

Scratch

This is a perspective that I keep simply to edit and update for transitory lists, lists that make sense to generate now, but not keep generally.

This might be a perspective to look at things tagged in more than one way (I use the default Tags perspective a lot), or a way of looking at my Next perspective, but excluding some kinds of things, for example.

I found that keeping a static perspective to edit as needed to be more efficient than creating a perspective and deleting it when done with it.

Project Groups

Okay, so these perspectives are really more for planning than for doing, but I wanted to keep my perspective design all together here.

I have four perspectives that look at my hierarchy of projects by folder (presentation of group and sort by entire project) as described above:

1. Active: these are my active outcome projects
2. Backburner: these are outcome projects that are on hold or deferred
3. Domains: these are my single action lists that represent areas of responsibility
4. Checklists: these are all my single action lists that represent opportunities of ideas for future action/projects

Conclusion

This all sounds like a lot of work. I’m not going to lie: initially, it is. But over time, these three dimensions need only look at new things (knowing), the shifts in progress and meaning of those things (planning), and leveraging in-place means for execution (doing). As such, maintaining becomes increasingly easy after establishing the overall architecture.

Real keys, I think, are defining how your system will work, being clear about what goes where and why, and then following those rules consistently.

Productivity isn’t a measure of how many things I accomplish. We are all always doing something, we are all always busy. Whether it’s finishing a client project or taking care of a home or binge-watching that series I missed, I’m always doing.

Productivity is a measure of how many of the best choices I make about what to do. I am “productive” when I work on the things that have the most impact, the most meaning, and that honour agreements and timelines. It’s not how many circles I check; it’s about which ones I check (and which I don’t).

The workflow I have described here, when I stick to it, is incredibly effective. It ensures that I know (or at least that OmniFocus knows) what all is in my life, carrying a total and complete inventory. It forces me to look at that inventory (when I am outside of the mindset of execution) and pare it down to the options I truly want to think about or consider when it comes to doing. It enables my doing with the presentation of only things I can or should do at a given moment.

In other words, I am kept productive. And sometimes, binge-watching that series I missed is exactly the best way to consider myself productive. Zero apologies.

---

Scotty Jackson is a productivity enthusiast who blogs about OmniFocus and other applications, strategies, and approaches at heyscottyj.com. He can also be found as @heyscottyj on Twitter and on Instagram.

---

❮ More Workflows