Open many people's task list and you'll see a six-week project sitting on the same line as "reply to that email." Same font, same checkbox, same visual weight. One of them takes two minutes. The other is a body of work that's going to eat most of your quarter. The list doesn't know the difference, and after a while, neither do you.

That's the flat-list problem. You need depth and layers!

Every list starts flat and useful. You add five things, you can see all five, it's fine. Then it's fifty things, then it's two hundred, and scrolling through it stops telling you anything. A flat list was never built to hold that much. It's one dimension trying to represent a job that has several.

The obvious fix makes it worse

The instinctive response is to add more fields. Tag things. Categorise them. Give each task a project label, a priority, an area. And this does work, right up until you notice what it costs: every one of those fields is a decision you now have to make at the exact moment you're trying to capture something. You've fixed the flat list and broken capture in the same move.

So the fields can't live on the task, decided by you, in the moment. The structure has to exist above the task, already built, so that a task can drop into it later without you doing any classifying yourself.

Three layers, not one

The way I set mine up, a Task is the smallest unit. One action, one line, done or not done. Tasks belong to a Project, and a Project is a real body of work with an actual description, not just a name. Not "Marketing." Something like "Rebuild the onboarding email sequence for new signups, currently three emails, needs to be five with better spacing." This should be a descriptive sentence, not a label.

Projects belong to an Area, which is the top layer, the domain the project sits in. Work, a specific venture, personal life, whatever the natural divisions are for what you're running. Some people don't need this layer at all, if everything they do sits in one domain anyway, and that's fine. Others need it badly, because without it, a work project and a house move look identical on the list.

There's a variant worth knowing about too. Instead of grouping projects by domain, you can group them by time period. A "Season," everything you're committing to in a given quarter, regardless of what kind of project it is. Same structural idea, different axis. Domain or time. Pick whichever one actually maps to how you think about your own work.

Why the description matters more than the hierarchy itself

Here's the part people skip. The hierarchy isn't really the valuable bit. The valuable bit is that each Project has a real description sitting behind it. That description is what makes it possible for a new task to find its way to the right project without you deciding in the moment, which is the whole point.

If "Rebuild onboarding sequence" is just a name, nothing downstream, a system, a future version of you skimming a list at midnight, can tell whether "fix the welcome email typo" belongs there or somewhere else. If it has a real description, the answer's obvious. You did the classifying once, up front, when you set the project up. Every task that follows rides on that decision for free.

The same principle applies one level up from where it usually gets applied. Decide once, structurally, ahead of time. Don't decide over and over, task by task, in the moment you're least equipped to do it.

What this looks like in practice

For me, every new task lands in a backlog first, and gets slotted into its Project automatically, based on which project's description it actually matches. I never manually file anything. The one piece of upfront work that matters is writing real descriptions when I set a project up, a proper sentence, not a label. Everything after that runs on its own.

If you're setting this up yourself, that's the one thing worth doing properly. Skip the temptation to just type a project name and move on. The name does nothing. The description is what carries the weight.

I built mine out fully, tasks, projects, areas, and the automatic routing between them, and wrote up how it works at singhos.com. Happy to walk you through it.