The right place is the place that answers the next question
The hardest part of a personal organisation app is rarely entering information. It is deciding where that information belongs. A single thought such as “sort birthday” could become a task, an event, a list, a note or even a small goal depending on what you actually mean. The easiest way to choose is to ask what question you will need the system to answer later. If the question is “what do I need to do?”, use a task. If it is “when is this happening?”, use the calendar. If it is “what items belong together?”, use a list. If it is “what information do I need to keep?”, use a note or reference.
This is more useful than memorising rigid definitions. Real life overlaps. A holiday may have a calendar event for the dates, a list for packing, tasks for booking transport and a note with useful information. Those records are not duplicates because each one answers a different question. Duplication becomes a problem when the same action appears in several places and you no longer know which copy is current.
Keep one source of truth for each action or commitment. You can link supporting records mentally or through names and search, but avoid writing the same task into a weekly plan, a list, a note and the task screen. The system should reduce the number of places you need to update when something changes.
Use Tasks for actions that can become done
A task describes something you can complete. Good task wording usually begins with a verb, even if you do not literally write it that way: call the dentist, compare quotes, email the landlord, order printer ink, finish the introduction. The task may have a due date, duration, energy level, context, notes or a link, but the defining feature is that there is an action to take and a meaningful point at which it becomes complete.
Do not use Tasks as a storage place for facts. “Boiler model X200” is not a task unless the action is to find or replace the boiler model. Put stable facts in Reference. Do not use Tasks for an appointment you are merely attending; put that in Calendar. If the appointment requires preparation, make the preparation a task. This keeps the task list focused on things you can act on.
Undated tasks are legitimate. A task does not need a fake deadline to exist. If you want to do something when there is time, leave the date empty and use status, priority, energy, duration or What now? to find it. Due dates are valuable precisely because they are not attached to everything.
Use subtasks when one task hides several decisions
A subtask is useful when completing the parent requires several distinct actions and you want those actions to stay attached to the same piece of work. “Prepare tax return” might contain download statements, collect invoices, check expenses and submit the return. The parent describes the overall outcome. The subtasks show the pieces. This makes progress visible without filling the main task list with unrelated-looking fragments.
The test is friction. If you see a task and immediately wonder where to begin, a subtask may help. If the task already tells you exactly what to do, leave it alone. Breaking “wash car” into find bucket, fill bucket, wash roof, wash doors and dry car adds maintenance without improving action. Structure should be earned by complexity.
Subtasks can have their own dates and details when necessary. A parent task may not be due until the end of the month while one subtask needs to happen this week. Life, Sorted. should still surface the parent when a child becomes relevant, so the smaller step does not disappear inside a task you are not currently viewing. That relationship is what makes subtasks more useful than separate copied tasks.
Understand what completion should mean for a parent task
A parent task and its subtasks need sensible completion behaviour. If you mark the parent complete while several subtasks remain open, the system should not quietly hide those unfinished steps. The safer approach is to make the relationship explicit: completing the parent can also complete its remaining subtasks after you confirm that this is really what you mean. That turns the parent checkbox into a deliberate statement that the whole outcome is finished.
Completing every subtask does not always mean the parent is complete. You might finish all currently known preparation steps and still need to wait for a final result. That is why automatic parent completion can be misleading. Leave the parent open until you decide the outcome itself is done.
Reopening a parent should not automatically reopen every child. The completed subtasks may still be historically accurate. You may only need to add a new step. This asymmetry is useful: completing the parent can close the remaining work with confirmation, while reopening the parent simply makes the outcome active again.
Use Calendar for commitments that occupy time
Calendar is where fixed commitments belong: appointments, meetings, travel, events, booked calls, deadlines you need to see on a date and anything where the time itself affects your plan. Calendar records should help you answer “what is happening around me?” rather than “what could I work on?” That distinction makes weekly and daily planning much more realistic.
Include location and a useful link when they will matter. A video-call link, booking page, map location or event page can save frantic searching later. Add short notes for preparation or context, but move substantial work into Tasks. If you need to prepare three documents for an appointment, those are actions, not calendar metadata.
When something moves, edit the event. Do not create a second copy and leave the old one behind. A calendar becomes trustworthy because each real commitment has one current record. Use the agenda for the forward view, the day view for detail and the week view to understand capacity.
Do not turn the calendar into a wish list
Some people schedule every task on the calendar because a coloured block feels more concrete than a task list. Time blocking can be useful, but it becomes dangerous when the calendar stops distinguishing commitments from intentions. A missed self-imposed block then looks like a broken appointment, and by Wednesday the whole calendar can become fiction.
Use calendar time for tasks when the time reservation itself is genuinely helpful: deep work you want to protect, a phone call that must happen during business hours or a task tied to a specific window. Otherwise, let Tasks hold the work and use Today’s Three or What now? to choose when to act. Your calendar should remain readable enough that a real appointment does not disappear among twenty aspirational work blocks.
If you do use time blocks, treat them as adjustable planning aids rather than moral contracts. Move or delete them when reality changes. The goal is to protect attention, not to create evidence that the day failed to match a prediction made three days ago.
Use Lists for collections that do not need individual workflow
Lists are ideal when the value comes from seeing related items together. Groceries, packing, gift ideas, films to watch, questions for an appointment, places to visit and checklists all fit naturally. The items can be completed, edited and organised into sections without pretending each one is a standalone commitment with its own priority and due date.
A grocery list item such as milk does not need to appear beside renew insurance and call the dentist. Keeping collections in Lists protects the meaning of the task screen. If buying groceries is itself a task because you need to remember the trip, create a task such as “do weekly shop” and keep the actual products in the grocery list.
Favourite the lists you reopen frequently. Archive lists that you want to keep but no longer need in the active view. Rename list items when they change rather than creating duplicates. Sections are especially useful for long lists that map to a real-world flow, such as supermarket areas or packing categories.
Know when a checklist should become a task with subtasks
Lists and subtasks can look similar because both contain smaller items. The difference is the outcome. A reusable packing checklist is a collection you may use repeatedly. “Prepare for conference” is a task or small project with steps that lead to a specific completion. If the child items only make sense in the context of completing one outcome, subtasks are usually the better fit.
A checklist may also be reference material. For example, “things to check before publishing a website” can live as a reusable list. When you are publishing a specific site, the task can link to or refer to that checklist. This avoids recreating the same quality-control steps as individual tasks every time.
Choose the representation that minimises future maintenance. Reusable material belongs in a list or reference. One-time work belongs in tasks and subtasks. If you find yourself copying the same subtasks into several parent tasks, that is a clue that the repeated structure might deserve a reusable checklist instead.
Use notes when the information is not an action yet
Ideas often arrive before they are ready to become tasks. A rough thought for a project, a meeting summary, a paragraph you want to keep or a set of observations can live in Notes without forcing a commitment. This matters because turning every idea into a task makes the task list emotionally expensive. Tasks should represent work you are willing to consider doing, not every thought you have ever had.
When a note produces an action, create the task in clear language and keep the note as supporting context if it remains useful. Do not leave an action buried in a long paragraph and expect Search to remind you at the right time. Notes preserve information; tasks create an actionable queue.
Pin a note when it needs frequent access. Search when you cannot remember where you filed it. The app should tolerate the fact that human memory remembers fragments rather than folder paths.
Use Reference for stable facts you will look up again
Reference is where recurring lookup information earns a permanent home. Model numbers, provider details, household instructions, travel facts, sizes, useful URLs and similar information belong there when they are likely to outlive a temporary note. The difference from Notes is not absolute; Reference simply signals that the information is intended to remain useful as a lookup.
Do not create a task just to keep a fact visible. If an action is connected to the fact, store both appropriately. “Broadband account renewal 3 March” can be a Life Admin record. “Compare broadband offers” can be a task. Provider contact details can be Reference or Contacts. Each record carries the kind of information needed for its own future decision.
Search connects these pieces without requiring a complicated relationship model. Use specific names and useful wording so the same provider, place or topic can be found across records when necessary.
Use Waiting On when you cannot take the next action
A task stops being a normal task when someone else has the next move. You have sent the email, requested the quote or submitted the form. Leaving “chase refund” on the active task list every day creates false actionability. Put the item in Waiting On with a follow-up date. Until that date, the correct action may be no action at all.
When the follow-up date arrives, the waiting item becomes a decision point. Chase, close, change the date or choose an alternative. If you then have a concrete action to perform, create or update a task. The screens remain useful because Waiting On holds dependency, while Tasks holds your own work.
This division is especially helpful in larger outcomes. A parent task may have completed all internal subtasks but remain open because you are waiting for approval. You can leave the parent open, record the dependency in Waiting On and close the parent when the actual outcome is finished.
Use Life Admin for obligations that persist beyond one task
Some responsibilities are not one-off actions. Insurance, subscriptions, licences, documents, bills and recurring renewals have a longer life. Life Admin can hold the provider, category, due date, recurrence, status and notes while Tasks holds the work required at a particular moment. This separation prevents permanent obligations from living forever as open tasks.
For example, keep “home insurance” as a Life Admin record. When renewal approaches, create a task such as “compare home insurance quotes”. When the task is complete, update the admin record with the new due date or status. The obligation persists while the action closes.
The same principle applies to documents and memberships. You want a durable place to see what exists and when it matters, plus short-lived tasks for actions. One record should not be forced to do both jobs badly.
Use Goals for outcomes, not for ordinary tasks with grand names
A goal is useful when the outcome will take multiple actions over time and when keeping the reason and direction visible changes how you choose work. “Finish professional qualification” can be a goal. “Email tutor” is an action. “Buy toothpaste” is not improved by becoming a wellness goal. Keep ordinary life ordinary.
Goal actions can appear alongside tasks when they are actionable, but they retain the link to the larger outcome. Milestones help when the goal has meaningful stages. The goal page is where you check whether the outcome still matters, not where you hide every task that sounds important.
When a goal completes or is released, open goal actions should stop appearing in today and task flows. Closing the outcome needs to close or remove its dependent action queue; otherwise the app continues asking you to do work for something you have already decided is finished.
Avoid creating parallel systems inside the same app
The most common source of confusion is not choosing the wrong module once. It is maintaining the same work in several modules. A task is copied into a weekly note, a list, a goal action and a calendar block. One version gets completed, another remains open, and trust falls apart. The cure is to decide which record is the source of truth and let other screens point to it.
Weekly priorities should refer to actual tasks rather than copied text where possible. Today should surface the existing task or event. Saved should be a shortcut to the original. Search should open the record you already have. This is how modules work together without becoming separate mini-apps.
When you notice yourself copying information, ask why. If the second location answers a genuinely different question, the extra record may be justified. If it exists only because you want the same action visible in two places, improve the view or shortcut rather than duplicating the action.
Choose the smallest structure that will still make sense later
You can organise almost anything into a complex hierarchy if you try hard enough. That does not mean you should. A personal system has to survive tired days, busy days, interruptions and weeks when you barely look at it. Simpler records are more resilient because they require fewer decisions to capture and fewer fields to keep current.
Add structure when you can name the problem it solves. Add a due date because timing matters. Add a subtask because the next step is unclear. Add a section because the list is hard to scan. Add a goal because the outcome needs direction over time. Add a reference because you keep looking up the same fact. Every field should have a job.
If you are unsure, capture the item in the simplest reasonable place and move on. Search, editing and weekly review give you opportunities to improve it later. The system should make imperfect capture recoverable rather than demand perfect classification at the moment your attention is somewhere else.
A few worked examples
“Dentist” could become several records without duplication. The booked check-up is a Calendar event. “Fill medical history form” is a Task. “Questions for dentist” is a List if there are several. The dentist’s contact details can be a Contact. A note about advice from the appointment can go in Notes. Each record has a different job, and Search can find them by the shared words you naturally remember.
“Move house” may be a Goal or a large parent task depending on scale. Viewings are Calendar events. “Send proof of income” is a task. Documents you repeatedly need can be Reference. Packing can be a List. Waiting for the letting agent belongs in Waiting On. Utilities and insurance can become Life Admin items. The system becomes a set of useful views of the same real situation rather than one enormous project page.
“Weekend away” can be kept much lighter. Put the travel dates in Calendar, create a packing list from the template and add one or two tasks for bookings still outstanding. You do not need to create a goal, project, milestone structure and review cycle for a simple trip. The right tool is the one that keeps the situation easy to understand.
If the app starts feeling crowded, fix placement before adding features
When a system feels noisy, it is tempting to look for new filters, tags or dashboards. First check whether the records are in the right places. Are reference facts sitting in Tasks? Are inactive goals still active? Are completed list items never cleared? Are waiting items mixed with actionable work? Are cancelled calendar events still present? Basic placement and cleanup often solve the problem better than another layer of organisation.
Then check whether views are surfacing too much. Today should be narrow. Saved should contain genuinely repeat-use items. Active lists should exclude archived material. Search can handle the long tail. A useful app does not need to show everything everywhere; it needs to make the right things visible at the right moment.
Once the boundaries are clear, features such as subtasks, favourites, sections and planning views become helpful rather than confusing. They add depth to an already understandable system. That is the sequence to protect: first choose the right kind of record, then add only the structure that improves the next decision.