# Purpose-driven vs system-driven design

Distinction articulated by Ryo Lu (Head of Design at Cursor, previously founding designer at Notion) in his [Dialectic](https://podcasts.apple.com/us/podcast/34-ryo-lu-its-all-the-same-thing/id1780282402?i=1000741808474) and [a16z](https://podcasts.apple.com/us/podcast/ryo-lu-cursor-ai-turns-designers-to-developers/id842818711?i=1000741517008) interviews. Surfaced in [[sail-muddy-lessons]] as part of why Sail/Muddy struggled.

## The two modes

**Purpose-driven design**: start from a specific user problem. Every screen is shaped to that problem. The product is described to users in terms of the problem it solves.

**System-driven design**: design flexible, universal concepts that compose. The product becomes a small set of primitives plus the ways they combine. Notion's blocks/pages/databases is the canonical example. The phrase Ryo Lu uses: "How few building blocks can you get away with?"

## Why systems are seductive

Sail did extensive "platonic decomposition" — finding the smallest set of concepts that compose into everything: web cards, text cards, comments, messages, threads, notifications. Groups and threads were the same concept (groups in canvas, threads of messages). Messages existed in both canvas and chat spaces.

For builders, this feels like finding a truth. The pivots between product forms (canvas → board → chat) become trivial because the plumbing is the same. The capabilities that emerge from primitive composition feel like leverage.

## Why systems usually lose

Users don't want to compose primitives. They want to know what the thing does for them. Sail's user reaction was always "that's cool" followed by not adopting.

Notion is the survivor case, but read carefully: aspirationally it's a "tool for thought," but in practice users describe it as "wiki / docs / project tracker." The system works because it cleanly maps to three pre-existing user purposes. The system is the implementation; the purpose is the marketing.

When you can't connect the system to a known purpose, you end up with "build your own workspace" — which puts the work of finding a use case on the user. Most users don't accept that work.

## The hybrid that works

Ryo Lu's own argument is that the discipline is to design *the system* but ship *the purpose*. Build the primitives so the product can keep evolving. But describe it, position it, and onboard users in terms of one specific problem. The system is for the team; the purpose is for the market.

## Related

- [[positioning-vs-vision-gap]] — the system always gets reduced to a one-line use case anyway
- [[dogfooding-trap]] — system-driven products especially benefit from external testing because primitives feel obvious to authors
- [[type-system-axes]] — a different domain where orthogonal concepts get conflated