Month: April 2026

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 provide maximum structural freedom while still enabling long-term clarity — without imposing hierarchy.

Context: Design Intent

Modern knowledge work increasingly requires individuals to design their own workflows rather than inherit fixed processes.

Tools have shifted from prescriptive systems toward flexible primitives.

Notion reflects this shift.

Instead of enforcing folders, task hierarchies, or rigid schemas, it provides composable elements — pages, properties, relations, views — and delegates structure to the user.

The intent is not to define architecture.

It is to enable it.

Freedom becomes the governing principle.

Primary Design Decisions

Decision: Commitment to Structural Primitives Over Prescribed Hierarchy

The system is organised around composable building blocks rather than predefined workflows.

This attempts to eliminate rigidity and accommodate diverse use cases.

What this deprioritises is immediate clarity. No dominant hierarchy is imposed by default. An alternative approach would provide opinionated templates that define structure from the outset.

Here, architecture must be authored.

Decision: Commitment to Database-Centric Architecture

Databases function as foundational objects capable of representing tasks, notes, projects, or knowledge structures.

This attempts to unify disparate tool categories under a relational model.

What this deprioritises is simplicity of mental model. Relational architecture introduces abstraction that must be maintained. An alternative approach would separate functions into distinct, simpler modes.

Abstraction increases expressive range.

It also increases structural surface area.

Decision: Commitment to Continuous Customisation

Properties, views, and relations can be modified at any time.

This attempts to support evolving needs without forcing migration to new systems.

What this deprioritises is structural stability. Ongoing modification lowers the cost of architectural change. An alternative approach would introduce friction for schema alteration, reinforcing commitment to chosen structure.

Here, refinement remains perpetually available.

Decision: Commitment to View-Based Clarity

Filtered and sorted views allow the same underlying data to appear differently depending on context.

This attempts to reduce information overload without duplicating content.

What this deprioritises is transparency of total architecture. Complexity can become distributed across layered views rather than visible in one place.

Perspective becomes configurable.

Structure becomes distributed.

Decision: Commitment to Universal Scope

The system positions itself as capable of supporting note-taking, task management, documentation, and knowledge systems within a single environment.

This attempts to reduce tool fragmentation.

What this deprioritises is singular identity. Without a dominant governing stress, architecture expands across multiple domains simultaneously.

Breadth replaces prescription.

Hierarchy Synthesis

The dominant priority of Notion is structural delegation.

Hierarchy is not enforced.

It is authored.

Flexibility governs prescription.

Optionality governs commitment.

The system protects freedom above coherence.

Where Complexity Appears

Complexity emerges not from feature accumulation but from iterative refinement.

As users pursue clarity, they add properties, relations, views, and filters.

Each addition improves local precision.

Collectively, they expand global structural surface area.

Over time, overlapping schemas, redundant properties, naming inconsistencies, and partial reorganisations can accumulate.

Nothing fails.

But hierarchy can become diffuse.

In systems where architecture is continuously adjustable, Decision Drift does not arise from imposed structure. It emerges from incremental optimisation — small improvements layered over time without periodic consolidation.

Freedom enables refinement.

Refinement enables layering.

Layering requires maintenance.

Cognitive Load

Initial constraint is minimal.

Users model information directly, shaping architecture to match thought.

Control increases.

So does responsibility.

Structural decisions must be remembered, updated, and occasionally reconsidered.

Clarity becomes an authored state rather than an embedded one.

The user carries both the power and the burden of hierarchy.

What We Would Remove

If forced to clarify the dominant intention further, immediate frictionless modification of core structural elements would be reduced.

Introducing resistance to schema changes would reinforce commitment and slow perpetual refinement.

Subtraction here would not remove freedom.

It would protect hierarchy from continuous adjustment.

What We Learned

When a system refuses to impose hierarchy, clarity becomes a responsibility rather than a feature.

Freedom enables precision.

Precision invites layering.

Layering demands maintenance.

Structural delegation empowers the user.

It also reveals how difficult sustained hierarchy becomes without constraint.

Every design solves something. The interesting part is deciding which problems are worth solving.

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.

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 provide frictionless note capture and retrieval while maintaining structural clarity across devices and contexts.

Context: Design Intent

Digital note-taking tools operate under competing expectations.

They must capture ideas instantly.
Organise information over time.
Remain accessible across devices.
Integrate with tasks, media, collaboration, and search.

These pressures create tension between simplicity at entry and complexity in accumulation.

Apple Notes appears shaped by a decision to reduce visible structure while quietly supporting long-term storage and retrieval.

The governing priority is lowered friction at the point of capture.

Primary Design Decisions

Decision: Commitment to Immediate Capture

The system prioritises fast note creation with minimal configuration.

This attempts to eliminate hesitation between thought and documentation.

What this deprioritises is upfront structural planning. Users are not required to choose templates, metadata fields, or predefined categories before writing.

An alternative approach would enforce structure at creation, increasing consistency while slowing capture.

Here, speed overrides classification.

Decision: Commitment to Hierarchical Folders as Baseline Structure

Organisation is anchored primarily in a familiar folder hierarchy.

This attempts to ensure long-term navigability using a widely understood structural model.

What this deprioritises is relational or networked organisation as the primary paradigm. An alternative approach would foreground tags or graph-based linking as the dominant organising principle.

Hierarchy is chosen over relational fluidity.

Decision: Commitment to Progressive Feature Exposure

Advanced capabilities — tagging, smart folders, scanning, attachments, collaboration — exist but are not visually dominant at first use.

This attempts to prevent overwhelming new users while accommodating expanding needs.

What this deprioritises is immediate visibility of full capability. A power-first interface would surface complexity early.

Instead, complexity is layered gradually.

Decision: Commitment to Device Integration Over Platform Independence

The system integrates tightly within a defined ecosystem.

This attempts to provide seamless synchronisation and continuity across devices.

What this deprioritises is platform-agnostic flexibility and user control over storage architecture.

Integration strengthens coherence within boundaries while narrowing portability.

Decision: Commitment to Mixed-Format Flexibility

Text, images, sketches, links, and scanned documents coexist within a single note without rigid formatting rules.

This attempts to prevent fragmentation of capture by allowing heterogeneous content to accumulate.

What this deprioritises is structural uniformity or metadata-driven precision. An alternative approach would separate content types into purpose-specific containers.

Flexibility replaces strict form.

Hierarchy Synthesis

The dominant priority of Apple Notes is restrained accessibility.

Ease of entry anchors the system.

Structure exists — but it remains visually secondary.

Immediate usability governs.

Organisational sophistication is deferred.

Where Complexity Appears

Complexity emerges not at entry, but over time.

As notes accumulate, secondary systems — tags, smart folders, shared documents — intersect with the primary folder hierarchy.

Hierarchical folders and tag-based grouping coexist as parallel organising models.

Individually, each is rational.

Together, they require interpretation.

When systems allow structure to expand progressively, accumulation becomes the defining stress. Without a clearly defended organising principle, scale can shift the experience from simple to layered — a gradual form of Decision Drift shaped by growth rather than feature addition.

The interface remains restrained.

The internal architecture becomes denser as volume increases.

Cognitive Load

At initial use, cognitive load is minimal.

Creating and storing a note requires almost no structural commitment.

Over time, organisational decisions become consequential.

Users must decide:

Which folder governs?
When to apply tags?
Whether search replaces structure?
How shared notes fit into hierarchy?

Complexity is distributed across time rather than imposed upfront.

Early friction is reduced.

Later interpretation increases.

What We Would Remove

If forced to clarify the dominant intention further, the system would prioritise either folders or tags more explicitly as the primary scaling model.

Reducing the visual equivalence of parallel organising pathways would strengthen hierarchy and reduce ambiguity about how the system is meant to evolve.

Subtraction here would not remove capability.

It would reinforce structural clarity at scale.

What We Learned

Restraint in interface design does not eliminate complexity.

It redistributes it.

A system that lowers barriers to entry must still govern accumulation.

Clarity depends on whether hidden layers remain anchored to a dominant structural principle as capability expands.

Friction removed at the beginning does not remove structural consequence over time.

Every design solves something. The interesting part is deciding which problems are worth solving.