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.
Leave a Reply