Okay, so a task is something that requires action, therefore it would make sense if all actions are sentences written in the imperative mood. So, why not require (or at least make it a convention) that tasks are simply a sentence written in the imperative mood? All other details of the task should be references (more on that later). With this, each task that is created is a command to do something and the person “completing” the task is the one confirming that the action was done (it’s a claim by that user). I argue this is all you need as a framework to be productive.
How do you handle more complex actions? The solution is to make each task “blocked” by their dependencies; all sub-tasks must be complete before a parent task can be completed. We only have one relationship between tasks and that is a one-way relationship: task A requires task B to be complete. We can call this a sub-task, dependency, or whatever. But this creates a hierarchy of tasks which describe workloads that require multiple steps and perhaps even parallelize the work between multiple people.
All work can be described using a task (and the tree/graph of tasks beneath it). This means a “project” is just a task: “Complete Project/Initiative”. A project “view” is merely all sub-tasks for the project task. The person who marks the project complete vets that it has been done in real life.
Where things get really interesting is when you have workflow designed around tasks. Currently workflow is thought of as moving tasks around some buckets which introduces another idea into the system and makes tasks have more than two states (instead of just incomplete/complete). Instead of adding more state to tasks, we could perhaps model our workflow as tasks. For example, in order to fix a bug you’d have sub-tasks such as “Figure out solution”, “Implement solution”, “Submit pull-request”, “Review pull-request”, “Verify solution fixes bug”, etc. Each sub-task here may not be created with the parent task right away, but rather the sub-tasks may be created as their needed because not all actions are known upfront in the real-world (sometimes no pull-request is needed for example). Now, the UI that we’re used to (kanban boards etc) can be templates or designs that create sub-tasks for our tasks as we drag tasks around in the UI; the underlying model isn’t change though. A list in a kanban board is a filter of all tasks with certain subtasks, and same with “sections”. All UI becomes “filters” or “queries” on the underlying data model (tasks which can have sub-tasks; trees).
Now, what about all the other things like fields, and what not? One idea I have is to remove description in favor for linking parts of the title out to some other object: “Implement feature A according to spec”. The link could be to a spec document for the feature. This replaces the need for the ambiguous field “description” with a directly correlated reference to some information that ties into the imperative mood of the task.
But what about fields which are merely there for organization; assignee, tags, categories, etc. Well, I think these could be modeled as tasks as well. An assignee is just a task like “Complete 's tasks for sprint ”. All of the tasks that would have been assigned to this person are sub-tasks for this task. The reference/link to this person in that task is something the UI could query for and even present all the sub-tasks in a nice “Your Tasks” view showing the top level tasks as sections and their sub-tasks as the actual work required. The same could be done for tags/categories: “Complete all <tag/category> tasks”. However, this means our tasks can have multiple parents, doesn’t it; our model isn’t really just a tree, it’s a graph!
Why am I proposing this model? I think keeping the mental model behind the tool as simple as possible is important for people to learn how to use the tool. If they know every task is just a sentence written in the imperative mood, then it’s clear what the contract between the user and the tool is: describe tasks as succinct sentences to convey the requirement to complete it. Then all the other things built on top of this fundamental idea is discoverable and flexible. Users can understand that a “project” is just a collection of tasks that are all related to each other in a uni-directional relationship. The tool can provide convenient automations that “build” the tasks they need according to the workflows they define. The tool queries what is just a graph dataset in many different ways without requiring the model to be extended or modified in order to get features that are useful to the user. Organization is just a matter of describing the work that needs to be done using this simple primitive idea, a task. Now the user can actually get the work done in real life, and spend less time learning new concepts and ideas to communicate the work that needs to be done. I imagine the tool will mold to the workflow of the team/organization as certain filters/automations are set in place all for the purpose of making it quick and convenient to make note and communicate of what is needed to be done to the entire team (This aligns with GTD methodology).
Furthermore, power users could develop integrations through an API to create automations that even Asana’s official app may not even be able to accomplish. These queries and automations could be rolled into 3rd-party apps and even in-house organization integrations that make sense to each unique organization.
Can we make Asana more like this?
