Naming and Framing: The Compressed Interfaces | Writing as the Primary Interface Tutorial

The Outsized Impact of Short Writing

A 2000-word essay gets read carefully by a few people and skimmed by more. A product name is read by every single person who encounters the product. A job title is read by every recruiter, candidate, and colleague. A tagline sits above every page of a website.

Short writing that lots of people read is the highest-impact writing you do. A good product name improves every sale. A bad one has to be overcome on every sale. Taglines, titles, and labels work the same way.

Most people spend far more time on long documents than on the short high-traffic writing. That's usually backwards. An hour spent choosing a good name compounds for years. An hour spent polishing the third paragraph of a blog post mostly doesn't.

Naming

Naming is hard because the name has to do several things:

Identify: make this thing distinct from other things
Describe: suggest what the thing is or does
Evoke: feel right for the audience and category
Survive: still work five years from now, across contexts you haven't anticipated

These goals pull against each other. A maximally descriptive name ("Enterprise Team Chat Platform") is dull. A maximally evocative name ("Sparkle") doesn't describe. The balance varies by category.

Categories of names

Descriptive: says what it is. "Dropbox" (a box where you drop things). "PayPal" (a pal that pays). Works when the description captures the thing and isn't a category collision
Evocative: a feeling or image. "Slack" (loose, relaxed, but also "slack" in a rope). "Notion" (idea, concept)
Coined: made-up words. "Spotify", "Xerox", "Kodak". Work if they become distinctive
Person/place: "Tesla", "Apple", "Patagonia". Ride on existing associations
Acronym: "IBM", "KPMG". Works mostly if the full name already had recognition

Most recent tech names are evocative or coined. Descriptive is out of fashion for products (though still common for features).

What to avoid

Exactly-descriptive + crowded category: "Chat App" won't work
Unintentional trademark conflicts: check before committing
Hard-to-spell or hard-to-say: you'll regret it every time a customer mispronounces it
Non-obvious international meanings: a word that's fine in English but rude in another language
Names that require context: inside jokes, obscure references. Fine for internal tools; bad for products

Testing a name

Say it out loud in a sentence: "I use X every day" or "Have you tried X?"
Type it into a URL bar: is the domain available (or some variant)?
Search it: what comes up? What do you compete with for the name?
Pitch it: can you say "X is a [category] that [does thing]" and sound natural?

Five minutes of the above kills most bad names.

Titles

Document titles, article titles, email subject lines, meeting names. Every reader sees the title; most decide from the title whether to engage.

Work-document titles

For memos, docs, and tickets:

Descriptive, specific, scannable. "Q2 pricing change proposal" beats "Thoughts on pricing"
Include the document's purpose. "Design doc:" or "Decision memo:" as a prefix helps
Include what it's about. Vague titles lose searchability later
Keep it short: under 10 words for most work docs

Good examples:

Design doc: Single-page checkout for v2 mobile app
Decision memo: Whether to switch from Stripe to Adyen
Incident review: June 12 API outage

Bad examples:

New Idea
Thoughts
Meeting notes
Proposal

These tell a searcher nothing. They're the equivalent of unnamed files.

Article titles

Titles of things people might read on the public internet:

Specific over clever. "Why async work produces better writing" beats "The new frontier of collaboration"
Numbers where relevant. "5 things I learned running..." is a cliché, but numbers still convert
Curiosity gap, honestly. Good titles promise something the reader wants to know. Bad titles ("You Won't Believe...") lie about what's inside

A reasonable test: if you only read the title, do you know roughly what the piece is about? If not, your title is working against you.

Taglines

Taglines live at the top of websites, in email signatures, on business cards. They're the shortest pitch.

A good tagline:

Says what the product is and who it's for
Promises something specific
Is memorable
Is true

Examples that work:

Stripe:    "Financial infrastructure for the internet"
Figma:     "Nothing great is made alone"
Linear:    "Purpose-built tool for planning and building products"
Notion:    "Your connected workspace for wikis, docs, and projects"
Superhuman: "The fastest email experience ever made"

Different styles. Each does the core jobs: tells you what and for whom.

Bad taglines are vague ("Unlock your potential"), clichéd ("Next-generation everything"), or generic ("Better, faster, simpler").

Labels

In interfaces, code, or documents, labels do quiet but critical work:

Button text
Form field labels
Section headings
Variable names
Navigation items

Good labels are:

Specific: "Cancel subscription" beats "Cancel"
Action-oriented for buttons: what will happen when I click?
Consistent across the product: don't use "Delete" in one place and "Remove" in another
Matched to the user's vocabulary: their words, not your internal jargon

Examples

Bad:     "Submit" button
Better:  "Publish post" button

Bad:     "User field"
Better:  "Email address"

Bad:     "Misc" section
Better:  "Advanced settings"

The bad versions are all technically functional. The better ones are specifically functional: they tell the user what the thing is.

Framing

Framing is about what comes first. The frame shapes what the reader does with everything that follows.

In a sentence

Compare:

"We missed our quarterly target, but sales grew 15%."
"Sales grew 15%, but we missed our quarterly target."

Same facts; different emphasis. The first sentence reads as positive with a caveat. The second reads as negative with a qualifier. Both can be true; the framing determines the takeaway.

In a document

The first paragraph sets the frame for the rest. A memo that opens "We have a critical problem..." sets a different context than one that opens "Here's an opportunity we can take...". The reader interprets everything after through whichever frame came first.

Choosing a frame

Frames aren't neutral. You're making a choice about how to present the information. Two disciplines:

Be honest. The frame shouldn't mislead. If the situation is bad, don't frame it as an opportunity; that's spin
Be intentional. If you're going to frame anyway (you always are), choose the frame deliberately instead of defaulting

A reasonable test: would the opposite frame be equally defensible? If yes, you have a choice to make. If no, the frame is just accurate.

Reframing

Sometimes the existing frame is wrong, and the move is to reframe.

A team feels stuck. Reframe: "we're not stuck; we're in the third week of a six-week problem"
A project looks behind schedule. Reframe: "we're on track against the revised scope"
A metric looks bad. Reframe: "this metric is the cost of our intentional choice to..."

Reframing can be manipulation. It can also be clarity. The difference is whether the new frame is more accurate than the old one.

The Naming-and-Framing Audit

A useful exercise: audit the high-impact short writing you're currently producing or maintaining.

Product names
Feature names
Page titles
Email subject lines (the recurring templates)
Button labels in your most-used interfaces
The taglines on your public surfaces
Your own job title

For each, ask:

Does it pass the five-minute test above?
Is it specific?
Does it say what it is to the target reader?
Would a better version be worth the rework cost?

You'll find a few that deserve a rewrite. The return on a weekend of renaming and reframing is usually larger than any single long document you could produce in the same time.

Why This Is Hard

Naming and framing are not hard because they're long. They're hard because the constraints are tight.

A 2000-word essay has room to explore; a bad sentence doesn't kill the piece. A 3-word name carries everything. Every letter matters. Small changes produce disproportionate effects.

The mental move: treat each short piece of writing like poetry, not like prose. Each word is considered. Alternatives are tested. The final version is the result of many drafts.

Most short work-writing gets a tenth the attention of long writing. It deserves more.

A Note on Renaming

Some short writing is hard to change once deployed:

Product names: expensive to rebrand
Domain names: can rarely move
Public feature names: get cited in external material

But most internal writing is renamable. A project code-named poorly can be renamed. A ticket queue with a bad name can be fixed. A feature with a weak internal label can get a better one.

Don't let "the name is stuck" calcify early. Most names can be changed; the cost is lower than you think, especially early.

Common Pitfalls

"The name doesn't matter; the product matters." The name is part of the product's surface. It affects acquisition, memorability, and how the product gets talked about. Understating it is common; it's also a mistake

"I'll name it later." Often fine; sometimes a trap. Placeholder names ossify. The temporary name becomes the permanent one. Either commit or set a deadline for the real name

"Clever is good." Sometimes. More often, clever is confusing. Specific and clear usually beats clever

"Our internal name is fine; customers won't see it." Until they do. Investors ask. Partners read docs. Employees reference it publicly. Names leak

"I don't have taste for this." Taste is trainable (see content/taste/). Reading good names closely, iterating on bad ones, and getting feedback develop the eye over months

Next Steps

Continue to 10-tools-and-workflow.md for the infrastructure around the writing itself.