GTD Interface Sketch
Getting Things Done
Earlier this month David Allen, the author of the immensely popular book and methodology: Getting Things Done (abbreviated as GTD), made a blog post titled "David Allen on the Best Software for GTD". After years of waiting for, and two attempts at creating the "Ultimate GTD" app without success, David decided to release his notes and sketches toward his ideal software available to the public.
As a adherent to GTD, this was a very interesting chance to take a look at what might have been, and to fantasize about what could still be a tremendous management tool. David remarks that the technology and interest to bring such a product to market wasn't there, but wants the idea to be released in case anyone can make it possible. While I'm certainly in no position to manage that on my own, it did inspire me to create my own vision of what great GTD software would look like.
If you aren't familiar with GTD, take a few minutes to orient yourself by watching this video.
The purpose of this design sketch is to try and capture David Allen's vision for what GTD software might look like. My goal is to mock up the more important features of the GTD system in a clean, intuitive, but ultimately complex project and task management system. Not everything is flushed out (yet?) but I did start with what I consider to be the essentials of the system: inbox processing, task listing, and projects.
The project assumes a desktop and/or web interface that can communicate with other instances of the software in a team setting. Details are below.
To view larger: Right Click > View Image
Inbox processing is really key to GTD. My design combines email, general process items (e.g., 'brain dump notes,' items sent from elsewhere in the system, reoccurring/scheduled items, etc.) and requests (sent from users in the system). This is meant to be a 'catch-all' location, so anything and everything that needs attention should drop here. From the inbox list the user chooses an item and is then prompted with a series of questions to help them organize it according to the GTD methodology. For experienced users who don't need the prompts for each task, shortcut keys can bypass the prompts and execute a particular action (e.g., create task, file in archive).
Tasks are the basic unit of the system. Under GTD, a task needs to include meaningful information to make it available and relevant to the user at the appropriate time and setting(s). This is done through the use of standard tags for each task. These include: (1) start/due date(s), (2) priority, (3) context, and (4) associated project(s). I added 'people' as another tag. Tags are used for sorting and grouping the task list.
The tasks are then containerized under action, waiting, or review.
All of these items can have due/review dates associated with them. Tasks with review dates in the future can be hidden to keep lists clean and so they appear at the appropriate time.
For my design, I adopted the 'card view' approach that users of different Kanban interfaces (e.g., Trello) are familiar with. The card includes the tag information on top, with action items on the right, and attachments at the bottom left. For certain tasks, an action button will appear (seen as "Call Now" in the sketch) for the user to complete the task - assuming there is an appropriate integration with external systems such as VoIP or email. This is otherwise a "Complete" button.
I also included a 'quick task add' feature that draws on the syntax made popular by TODO.TXT which uses symbols to denote tag type (e.g., +project-one, @errand, &john-doe) with an option for prompts.
Projects are the larger GTD container that includes tasks, notes, plans, and members. There are three types of GTD projects: current, future, and possible (or prospective).
Possible projects are 'weak' future projects that may just be ideas and a few associated tasks. These are included in the review process where they are either further developed, deferred, archived, or deleted.
These features are not well-defined (yet) but would be included in the software ideally.
This was a fun design exercise for me. I've received a lot of benefit from emulating the GTD method over the years and so fantasizing about what my ideal software might look like was a bit like designing a dream home. I still have some unpolished elements that I may develop and upload in the future if the mood strikes me, but for now the process has caused me to look at my own GTD system with renewed enthusiasm and a critical lens.
While David mentions in his article that he doesn't think the technology is quite there for an ideal GTD system, I think there are a number of open source projects that have taken the methodology to heart in small ways. In the future It would be nice to see unite under one free and open source effort.