GTD Interface Sketch

Getting Things Done

Pencil

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.

My Design

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

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

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.

• Action tasks are sorted by priority and context by default.
• Waiting tasks are tasks that are 'out' - either on hold or sent to someone else to complete.
• Review tasks are 'weak' tasks that are processed during the Inbox review process.

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.

TASK CARDS

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. 

QUICK TASKS
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

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).

• Current projects are well-defined and active
• Future projects are well-defined but dormant
• Possible projects are weak-defined and dormant.

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.

OTHER
These features are not well-defined (yet) but would be included in the software ideally.

• Contacts - Standard contact database
• Notebook - Rich-text notes (either markdown or HTML), GTD recommends an alphabetical sorting model
• Archive - File manager, GTD recommends an alphabetical sorting model
• Goals - Personal and professional goals, these are included as part the the daily/weekly review process to keep the user's defined goals in mind. This could be further developed into a LMS/LRS integration using pathways/badges
• SDMs - Someday/Maybes - These are small idea notes that don't fall into the rest of the system. They are included as part of the review process and turned into projects/tasks, deferred, archived, or deleted.
• Integrations: video/voice/text messenger, email, RSS feeds

Final Thoughts

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.