Subtasks: make completion and ownership clear

Distinguish a child task from a checklist item

ClickUp exposes Subtasks, Checklists and Relationships as separate sections in a task detail view. MinimaList places smaller work items directly under a primary task and offers Add subtask. The contrast is useful: a rich work object needs different affordances from a quick line in a personal plan. Do not make the distinction depend only on indentation that disappears in a search result.

If a child can have its own owner or deadline, expose a route to its detail view and retain its parent identity there. If it is only a checklist line, avoid controls that imply independent scheduling. Use action labels that match the object being created, and keep the parent title visible while the keyboard is open. A person adding five small steps should not need to repeatedly reopen a full task composer.

For implementation, give every item a stable identity before it can be reordered or edited offline. The text of a subtask is not an identifier; duplicate labels are ordinary. Save draft lines intentionally and explain whether pressing return adds another line or commits the entire parent. Test empty lines, pasted multi-line text and a failed save without losing the work already entered.

Make the parent and order visible

TickTick’s Link Parent Task sheet includes search, a selected parent and Done. Tiimo’s task form shows a Sub-tasks section with individual drag handles. These are two different structural operations: choosing where a task belongs and changing the order of work within it. Neither should be represented by a generic Move action without a destination summary.

When linking to a parent, show enough project context to distinguish identical titles. Exclude impossible destinations, including the task itself and its descendants. If nesting depth is limited, explain the limit before selection. After applying the relationship, show the new parent in the destination view and provide a way back. Do not unexpectedly relocate the person to a different project merely because the relationship changed.

For ordering, define whether the list is manual, due-date sorted or automatically sequenced. A drag handle is misleading when the next refresh will immediately overwrite the order. Provide an accessible reorder alternative with clear announcements, and keep the moved item focused. When another collaborator edits the same list, reconcile by stable item identifiers and preserve the user’s text rather than replacing the whole list blindly.

Explain the count and the completion rule

Todoist shows Sub-tasks 1/1 alongside a Completed snackbar with Undo. Focus Keeper shows a child checkbox and a drag handle below the task title. The visible count and independent checkbox invite an important question: does every checked child imply that the parent is finished, or must the parent be completed separately?

Choose a rule that matches the work. If the parent represents approval or delivery, completing its preparation steps may not complete the outcome. If it is simply a checklist container, automatic completion may be appropriate. In either case, explain exceptional behavior at the action: Complete task and 3 open subtasks is clearer than a checkmark that silently changes several records.

Count the intended set consistently. If completed children are hidden, a 1/1 summary should not look like a list with nothing in it. If some children are cancelled or inaccessible, do not present them as unfinished work the user can fix. Keep completion separate from deletion and preserve the event needed for Undo. A server failure after a local check should restore the right item, not reopen every child in the parent.

Keep completed work discoverable

Todoist’s task menu offers Show Completed Sub-tasks, making the existence of a hidden completed set explicit. FamCal’s New task form places several subtasks below shared scheduling and reminder settings. Together they suggest a useful separation between the current visible list and the historical work attached to a parent.

Do not make hiding completed work equivalent to removing it. Retain a count or a discoverable control, especially when someone is auditing a shared task. On reopening, state whether the app reopens only the parent or its completed children as well. For repeated tasks, determine whether each occurrence gets fresh child instances or reuses the same checkboxes; otherwise yesterday’s completion can incorrectly appear in tomorrow’s plan.

Shared reminders deserve their own scope. A parent notification preference does not automatically explain whether collaborators are notified when every small child is checked. Show the relevant behavior in settings or a concise description. Use a history entry when structure changes matter, but avoid turning every keystroke into noise. Review whether people can answer what changed without exposing unnecessary personal activity.

Name the children affected by a destructive action

Todoist’s confirmation explicitly says that deleting the parent will delete its one subtask, and its destructive action repeats that scope. FamCal’s Edit Task view shows the parent and three child items above Delete. The latter screen does not show its confirmation, so it is a useful prompt for what to inspect next, not evidence that deletion cascades safely.

If deleting a parent removes children, name the count and offer an appropriate recovery path. If it detaches children, show where they will go. Do not describe deletion as archiving unless recovery really exists. Revalidate the affected set before committing a shared operation: a collaborator may have added a child since the confirmation opened. If the scope changed materially, return to confirmation instead of deleting an unseen item.

Build the failure path with the same care as other mobile app error states. Test incomplete permissions, offline completion and a parent changed on another device. Ask users to predict what will remain after completion, reopening and deletion. Measure mistaken cascades and recovery success rather than claiming an indented list makes people more productive.

Test competing changes on the same parent

Prepare a parent with three children: one completed, one assigned elsewhere and one containing an unsaved edit. Complete the parent on another device, then return to the first device. Decide in advance which operations are allowed and how the conflict is communicated. A stale local checkbox should not silently overwrite a collaborator’s new text or turn an unavailable child into an apparently completed one.

Keep structural operations distinct from status events. Moving a child changes its parent relationship; completing it changes its work state. Applying both as a whole-list replacement can accidentally delete work created between refreshes. Test by stable identifiers and preserve the user’s unsaved text through any reconciliation screen. If a conflict cannot be resolved automatically, show the specific child and choices.

Record accidental cascade reports and undo success alongside task completion. A user who completes everything quickly may simply have misunderstood a parent checkbox. In moderated review, ask them to predict the outcome of reopening the parent and deleting it. Those explanations reveal whether the hierarchy is understood more reliably than counting taps or measuring a faster animation.

Test the whole parent-child contract

Use these checks on a working build, not only on the polished reference state.

• ✓Distinguish an independently editable child task from a simple checklist line.
• ✓Show parent identity when a child is opened from search, reminders or a shared link.
• ✓Prevent self-parenting and cycles, and explain any depth or permission limit.
• ✓Define counts for completed, hidden, cancelled and inaccessible children.
• ✓Specify parent completion, reopening and recurring-occurrence behavior separately.
• ✓Keep reorder usable without dragging and retain stable focus after an edit.
• ✓Name cascading deletion scope and handle newly added children before confirmation.