The No Modes pattern solves User Action Congestion by removing the need for the user to choose what mode they are in before acting.
The problem: User Action Congestion
User Action Congestion happens when too many possible actions compete for the same UI space or mental space.
For example, in Seed a user may be looking at a document and want to:
read
edit
comment
cite
copy link
select blocks
move blocks
open version history
open people
reply to a conversation
create a child document
inspect references
If the interface exposes all of these as buttons, tabs, menus, toolbars, sidebars, and modes, the user has to constantly ask:
“What mode am I in?”
“Where is the action I need?”
“Do I need to select first?”
“Am I commenting, editing, navigating, or organizing?”
That creates congestion.
How No Modes helps
The No Modes pattern says:
The object should remain the same. The user action should emerge from context.
Instead of switching between separate modes like:
Read mode
Edit mode
Comment mode
Select mode
Move mode
Cite mode
Organize mode
…the user interacts directly with the document, block, comment, card, or selection, and the relevant actions appear only when needed.
So the UI changes from:
“Choose a mode, then act.”
to:
“Point at the thing, then act.”
Example in Seed
Bad modal design:
Click “Comment mode”
Select text/block
Write comment
Exit comment mode
Enter edit mode
Edit block
Enter citation mode
Add citation
No Modes design:
Click into text → edit
Select text → actions appear: comment, cite, copy link
Hover block → block handle appears: move, copy, reference
Open comment thread → reply box appears inline
Drag document/card → organize it
Type / → create structure or insert object
The user never thinks “which mode am I in?” The object itself reveals possible actions.
Why it reduces congestion
No Modes reduces congestion in three ways.
First, it hides irrelevant actions until the user has given context. A blank document surface does not need to show every possible action. Once the user selects text, only text-relevant actions appear.
Second, it localizes actions near the object. Actions belong to the thing being acted on: block actions near blocks, comment actions near comments, document actions near documents.
Third, it turns global controls into contextual affordances. Instead of one giant toolbar containing everything, each object exposes a small set of meaningful actions.
The deeper principle
The interface should not be organized around application modes.
It should be organized around objects and intentions.
In Seed terms:
Document → read, edit, publish, cite, version
Block → select, move, comment, reference, transclude
Comment → reply, resolve, quote, link
Person → view contributions, mention, follow
Citation → inspect source, navigate, quote
Board card → move, prioritize, open document
Each object carries its own action surface.
The tradeoff
No Modes does not mean “no state.” The system still has state: selection, focus, hover, active thread, current document, current draft.
But the state should be lightweight, visible, and reversible.
Bad mode:
“You are now in Comment Mode.”
Good contextual state:
“You selected this sentence, so Comment is available.”
Product sentence
You could describe it like this:
The No Modes pattern reduces User Action Congestion by making actions contextual to the object under focus, instead of forcing the user to switch between global modes. The interface stays centered on the document, while editing, commenting, citing, linking, and organizing emerge from selection, focus, and intent.
For Seed, this is especially important because the product is not just an editor. It is a relational workspace. Without No Modes, the number of possible actions will explode. With No Modes, the document remains calm, and the network reveals itself only when the user touches the relevant object.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime