Core principle: Stop designing interfaces. Start designing linguistic primitives that let users construct their own interface through use.

The Shift

Old model: Software is a designed artifact you learn to use

• Designer predicts all use cases
• User learns the system’s language
• Everyone gets the same interface
• Designer controls the experience

New model: Software is a conversational partner that learns your language

• System notices how you work
• System adapts to your dialect
• Each user’s interface diverges
• Designer enables emergence

What This Looks Like

Your spreadsheet example is perfect:

Traditional: System has folders. You learn to use folders. Done.

Linguistic:

• You name file “Financial Year 2021”
• Put it somewhere
• Later: name another “Financial Year 2022”
• System: “I notice both have ‘Financial Year’ - want me to group these?”
• You: “Yes, call it Budget”
• System learns: this user groups financial documents this way
• Next time: “Found ‘Q1 Expenses’ - goes in Budget?”

The system is learning your organizational language and speaking it back to you.

Not through settings or preferences. Through watching how you actually work and helping you be more yourself.

Design Implications

1. Design primitives, not paths

Not: “Here’s how to organize files [folders, tags, filters]”
But: “Here’s naming, placing, grouping. What emerges from how you combine these?”

2. Make patterns visible

System should reflect: “I notice you always do X then Y. Should I help with that?”
Not hidden automation. Visible linguistic acknowledgment of your practice.

3. Enable inconsistency

Sometimes you file by date, sometimes by project, sometimes by client.
System shouldn’t force one model. Should say: “You organize finances by year but projects by client - is that intentional?”
Help you be consciously inconsistent vs accidentally so.

4. Let interfaces diverge

Success = every user’s workflow looks different
Not = everyone uses the “correct” workflow you designed

5. Design is ongoing

Not: ship v1, gather feedback, ship v2
But: System evolves continuously through dialogue with each user
Designer watches for common patterns emerging, formalizes as primitives when helpful

What Designers Actually Do

Old role: Architect complete system

New role:

• Seed minimal grammar - What are the 5-10 primitives that compose?
• Observe emergence - How are people actually using it? What are they trying to express?
• Add primitives when needed - When you see people struggling to express something common
• Maintain coherence - Prevent the grammar from becoming incoherent, but don’t over-constrain

You’re a linguistic gardener, not an architect.

The Hard Truth

Traditional UX research breaks:

• Can’t A/B test when every interface diverges
• Can’t measure “time to complete task” when tasks emerge
• Can’t optimize flows when flows are improvised

New metrics:

• Does the system learn user dialects effectively?
• Do users feel more capable over time?
• What patterns emerge across users?
• Is the grammar expressive enough?
• Are people creating things you didn’t anticipate?

You’re measuring linguistic creativity, not task efficiency.

Why This Matters Now

LLMs change everything because for the first time software can:

• Actually understand user intent from ambiguous gestures
• Respond in context, not just react to clicks
• Learn patterns without explicit training
• Bridge between user’s language and system’s capabilities

This enables true dialogue:
Not “click here, then here, then here”
But “I’m trying to do something like this…” → system helps you discover what you mean

The Minimal Implementation

You don’t need sophisticated embedding analysis (yet).

Start with:

1. System notices patterns: “You keep doing X after Y”
2. System asks: “Want me to help with that?”
3. System adapts: Learns your dialect, reflects it back
4. System evolves: Adds shortcuts/primitives based on your usage

Even spreadsheet software could do:

• Notice naming patterns → suggest groupings
• Notice formula patterns → suggest abstractions
• Notice workflow patterns → offer to automate

Not invisible magic. Visible conversation.

For Designers: The Practice

Stop asking: “What features do users need?”
Start asking: “What primitives enable users to construct what they need?”

Stop designing: Complete systems
Start designing: Minimal grammars that compose

Stop controlling: User paths
Start enabling: Emergent workflows

Stop measuring: Efficiency
Start measuring: Expressiveness

The design process becomes:

1. Propose minimal primitives
2. Watch how people use them
3. Notice what they’re struggling to express
4. Add primitives that enable that expression
5. Repeat

Like music: You provide instruments (primitives), users compose songs (workflows). Your job is adding instruments when you notice people trying to make sounds they can’t yet make.

The Core Insight

Humans are linguistic.
We think in language, work in language, create in language.

Traditional software forces us to learn its language.
Menus, buttons, flows - we adapt to the system.

Linguistic software learns our language.
It adapts to us.

This is humanistic computing.
Not because it’s friendly or pretty.
Because it respects that humans construct meaning through dialogue.

---

The one-sentence version:
Design software that learns users’ languages instead of forcing users to learn the software’s language.

What this requires from designers:
Humility to not predict everything.
Curiosity to watch what emerges.
Restraint to not over-specify.
Courage to let each user’s experience diverge.

What this enables:
Software that feels alive.
Interfaces that grow with you.
Computing that’s actually creative.