We don’t review products to decide whether they are good or bad. Most are both. We study them to understand the decisions behind them — what problems they prioritise, what trade-offs they accept, and where complexity appears. Every system is a set of decisions. This is an attempt to understand those decisions.
Problem Statement
The system attempts to reduce ambiguity in task management by enforcing a linear hierarchy that prioritises progression over flexibility.
Context: Design Intent
Task management tools frequently expand as workflows become more complex.
Labels multiply.
Filters layer.
Metadata accumulates.
Relational links proliferate.
Flexibility increases.
Hierarchy weakens.
Things 3 appears shaped by an opposing philosophy: impose structure early and protect forward movement rather than optimise for architectural freedom.
The governing priority is momentum.
Primary Design Decisions
Decision: Commitment to a Fixed Hierarchy Model
The system enforces a predefined structure — Inbox, Projects, Areas, Upcoming, Anytime, Someday.
This attempts to eliminate structural indecision by providing an explicit progression model.
What this deprioritises is user-authored hierarchy. The structure cannot be deeply modified or redefined. An alternative approach would allow custom databases, schema creation, or relational overlays.
Here, architecture precedes preference.
Decision: Commitment to Linear Task Flow
Tasks move forward through stages rather than existing in multi-relational states.
This attempts to reduce scattered attention by emphasising sequence and continuity.
What this deprioritises is complex cross-tagging or dynamic filtering across multiple contextual dimensions. A relational system would allow tasks to inhabit several conceptual categories simultaneously.
Linear flow constrains ambiguity.
Decision: Commitment to Minimal Metadata
Things 3 limits properties, custom fields, and structural attributes.
This attempts to reduce over-organisation and eliminate excessive classification decisions.
What this deprioritises is granular tracking and precision categorisation. A metadata-heavy system would enable analytical depth but require structural maintenance.
Here, omission is deliberate.
Decision: Commitment to Constraint Over Customisation
The system offers limited deep configuration.
This attempts to protect structural integrity by preventing user-authored drift.
In many productivity systems, gradual customisation can accumulate into fragile micro-architectures — personalised structures that obscure the original governing model. By limiting expansion, Things 3 prevents such divergence.
The trade-off is reduced adaptability for unconventional workflows.
Constraint preserves clarity.
Decision: Commitment to Focused Interaction
Interface elements prioritise the next actionable item rather than presenting the full architectural overview.
This attempts to reduce cognitive overload by narrowing attention.
What this deprioritises is panoramic visibility of system structure. A dashboard-heavy approach would foreground architectural mapping.
Here, interaction reinforces progression.
Hierarchy Synthesis
The dominant priority of Things 3 is disciplined progression.
Hierarchy is imposed.
Optionality is restricted.
Momentum is protected.
Clarity emerges from limitation.
Where other systems expand to accommodate nuance, this one narrows to preserve flow.
Where Complexity Appears
Complexity emerges not from feature accumulation, but from tension between imposed structure and evolving workflow demands.
As user needs expand, the fixed hierarchy can feel constraining.
Tasks that resist clean categorisation expose the rigidity of the model.
The system resists adaptation. That resistance is intentional.
In productivity environments, gradual addition of metadata, tags, and relational links often leads to Decision Drift — not through error, but through incremental customisation that erodes a coherent organising principle.
Things 3 guards against that pattern.
The cost of this defence is reduced expressive freedom.
Cognitive Load
By enforcing structure, Things 3 reduces architectural decision-making.
Users spend less time designing systems and more time executing tasks.
Structural ambiguity is minimised.
However, when tasks exceed the imposed model, cognitive load shifts toward workaround behaviour — reinterpreting categories or compressing nuance into simplified buckets.
Constraint reduces drift.
It also limits nuance.
What We Would Remove
If forced to clarify the dominant intention further, the ability to simulate structural flexibility through deeply nested subtasks could be reduced.
Strengthening flat progression would reinforce linear clarity and prevent hidden micro-architectures from forming within projects.
Subtraction here would intensify commitment.
What We Learned
When a system chooses hierarchy over flexibility, clarity becomes a byproduct of constraint.
Imposed structure reduces optionality and accelerates flow.
The cost is adaptability.
The benefit is decisiveness.
Discipline, embedded in architecture, can substitute for user-authored organisation.
Every design solves something. The interesting part is deciding which problems are worth solving.
Leave a Reply