304. Headlines, taglines, names

A heading can be short enough to remember and still leave you wondering what the page is about. “A clearer view” might introduce a proofing tool, a window cleaner or a change of opinion. The words are agreeable. The reader needs one more useful fact.

A headline identifies a subject and gives someone a reason to continue. A tagline carries a more enduring position. A feature name helps people find and discuss the same thing across the app, its documentation and a support conversation. They all benefit from close attention to words, but they have different jobs.

The craft is to choose the detail that can carry the line. Keep enough context for the reader to understand it, then decide where the sentence should land. Sometimes a plain noun does more work than an elaborate turn of phrase.

Write the claim before the headline

Use this fictional product packet throughout the first workshop:

• A proofing app displays two chosen PDF proofs side by side.
• It does not automatically mark differences.
• The reviewer decides which proof to approve.
• Its demo can display comparisons but cannot save them.
• No measured time saving has been supplied.

The literal claim is already useful:

Display two PDF proofs side by side.

It names the objects, their arrangement and the action. It does not yet explain why someone might want that view. The next draft can put the reader's work first:

Compare two PDF proofs in one view.

This is a candidate for the product page. It describes human comparison; it does not promise that the app detects differences. The deck can make that distinction explicit:

Place the chosen proofs beside each other and inspect the pages yourself. The app provides the view; you decide what to approve.

Now there is room to try a more expressive candidate:

The other proof is beside this one.

That line directs attention to the arrangement, but it gives a newcomer less information than the literal version. It might serve as a caption under the comparison image. On a page without that image, the clearer candidate wins.

The workshop has produced a headline, a deck and a possible caption. It has also shown why moving the same words to another surface can improve them. A rejected headline need not be a bad sentence.

Generate useful differences

Start with alternatives that offer different points of entry. Changing better to smarter does not produce a new idea.

For the fictional tool, try:

Entry	Candidate	What it asks the reader to notice
Task	Compare two PDF proofs in one view	The review work
Arrangement	Put the two proofs side by side	The visible relationship
Human judgment	Two proofs to inspect. One decision to make.	The approval task, when that is the page's stated purpose
Demo	Try a side-by-side PDF comparison	A way to examine the view before buying

The third line has more rhythm, but it also narrows the situation to one approval decision. Use it only in that context. The demo candidate needs the no-save condition beside its invitation. None supports “Find every change automatically.”

Draft enough alternatives to explore the actual choices. There is no required count, and exhaustion is not evidence of quality. Once several candidates test different useful emphases, compare them with the brief and their support. Keep a promising plain version while experimenting. It gives you something substantial to return to.

Give the ending something to reveal

A sentence prepares its last phrase. You can use that expectation to sharpen an observation without making a puzzle out of the subject.

Suppose an article uses the fictional proof tool to explain the difference between showing documents and deciding which one to approve. Its heading and opening might be:

The comparison ends with your decision

The app can place the proofs together. It cannot tell you which drawing to prefer, whether a correction answers the brief or whether the next version should be approved. Both proofs are visible; the judgment is yours.

The heading names the article's subject, and the opening develops it through particular decisions. The final sentence settles a distinction the paragraph has earned. It would be excessive as a repeated formula on every page.

For a product-page headline, the shorter task candidate may work better. The space available and the reader's question decide how much development belongs near the top. Put a condition before the action it governs, even when delaying it would produce a more dramatic ending.

Choose a form that fits the page

A statement is useful when the fact is the news. Name the change and its scope. A version number can locate it; an adjective such as advanced usually needs an explanation before it helps.

A task heading promises instruction. “How to compare two PDF proofs” should lead to a method using verified controls and a clear result. If the page merely offers a product, give it a product-page heading. Readers should not have to buy something to discover that the promised lesson was absent.

A question can frame a real uncertainty. “Which proof does this comment refer to?” can lead into an explanation of comment locations. The page must answer it. A useful question can have no as its answer; a help article titled “Can the demo save comparisons?” is doing useful work by saying no immediately.

A count or comparison needs evidence and a meaningful basis. Four variants means four variants. A speed comparison needs its tested version, inputs and method. Do not make a number smaller merely to make it sound believable, and do not borrow a historic benchmark for a different release.

A category and audience line can orient a newcomer. Choose nouns the audience uses for the product and the task. Adding “for professionals” to an otherwise vague promise gives the reader little to examine.

These forms are starting points. A page may need a straightforward topic heading with no explicit sales claim. A heading about licensing, for instance, can say “Licensing.” The subject is the reason to read.

Let the deck advance the thought

The deck is the short passage beneath the headline. It should add something: a mechanism, a scope, a reason, a relevant condition. Repeating the heading in more enthusiastic language uses the space without developing the idea.

For the fictional tool:

Headline: Compare two PDF proofs in one view

Weak deck: A powerful way to take your proof comparisons further.

Useful deck: Choose the two documents and inspect them side by side. Difference detection and approval remain your work.

The useful deck says what the app contributes and what the reviewer does. For a demo section, continue with the boundary:

Try the comparison view in the demo. Comparisons cannot be saved there.

Do not make every deck carry the entire specification. Choose the information that changes the reader's understanding or next decision, and give the rest a clear place on the page. A deck can be one developed sentence if its clauses remain easy to follow.

Read each heading with the first sentence below it. If both make the same point, use the second to move forward. If they make different promises, resolve the difference before polishing either.

Write the version that travels alone

A headline may appear in a link, an email or a search result without its picture and neighboring text. Examine those uses explicitly.

For the fictional product page:

Surface	Draft
Visible headline	Compare two PDF proofs in one view
Page title	PDF proof comparison: side-by-side review
Short description	Display two chosen PDF proofs together for manual review. The demo displays comparisons but cannot save them.
Link to the help article	Compare two PDF proofs

These versions retain the topic and the scope. A page title is still written for people; it need not become a list of loosely related search terms. Use the product or feature name where it helps identify the destination.

A visual joke may work well in a campaign whose image is always present. If the line will also be used without that image, supply an appropriate standalone version. Test the real pair as well as the isolated text. Typography and imagery can contribute meaning; they cannot rescue a false claim.

For an international audience, check whether an idiom carries an essential part of the message. A dry turn can survive translation when it rests on the situation rather than a double meaning. Preserve the subject and relationship even when the local version needs a different rhythm.

Taglines need a settled position

A tagline follows a product across more situations than one page's headline. It should express a position that remains useful there. That may take the form of a transformation, a kind of work or an approach to that work.

For the fictional proofing app, these are draft directions, not approved names or claims of exclusivity:

Too vague: Clarity for every possibility.

Concrete direction: A place to compare your proofs.

More compressed: Your proofs, together.

The concrete direction tells a newcomer more. The compressed version needs the surrounding product identity to make its subject clear and may suggest a broader collection of proofs than the supported pair. That is something to resolve, not a reason to admire its brevity.

Choose the position before treating a tagline as finished. Read it beside the actual product pages and ask what it promises across them. Check whether it implies a guarantee, an unsupported audience or a capability that exists only in one version.

A competitor's ability to use the same words can reveal weak differentiation. It does not automatically make the line useless. Sometimes a clear category description is what the reader needs first. Distinctiveness must come from a real difference, not a novelty added to escape a comparison.

Name a feature for repeated use

A feature name will appear in instructions, menus, screenshots and questions. Try it in those places before judging it on a presentation slide.

Suppose the fictional app's side-by-side display needs a name. Proof view and Comparison view are draft candidates. Instant Approval is a poor candidate because it implies a decision the app does not make.

Test the candidates in ordinary sentences:

Open Comparison view.

Which two proofs are shown in Comparison view?

The comment is attached to a page, not to the view.

The last sentence tests whether the name helps distinguish objects. A memorable name that confuses a document with its display will keep demanding explanations.

A brief naming sheet can record:

• The feature's actual behavior and the object being named.
• Candidate names, their likely meanings and any collision with existing terms.
• The short explanation a new reader needs.
• How each candidate works in a menu, procedure and support question.
• Its status: proposed, approved, current or retired.

Descriptive names often work well. Evocative names can work too, if the first explanation makes their scope clear. A name need not explain the whole feature, and every appearance need not repeat the same gloss. Supply it where this reader needs it.

Keep draft names visibly provisional. Check the applicable naming and owner requirements before publication; an editorial shortlist does not establish availability or approval.

Keep the name recognizable

Use the approved spelling and capitalization even inside a sentence-case heading. FontLab names the product; Fontlab Ltd. names the company. Consult the product-name guide for current forms and status.

Refer to a feature consistently. You can use a clear pronoun or a descriptive explanation after naming it, but do not invent a second apparent label merely for variety. Readers may need the exact term for search or support.

Write literal actions around the name. “Turn on Power Nudge” identifies a setting and an action more clearly than treating the entire feature name as a verb. This is an editorial distinction; do not invent a legal consequence for an ordinary grammatical choice.

When a name changes, help readers arriving under the old name find the current one. A migration note can use “New name, formerly Old name” when that history is verified. Update current headings, descriptions and interface references while preserving historical quotations and version-specific instructions where their old wording is necessary. Explain those cases instead of silently rewriting history.

A rename review should include screenshots, captions, alternative text, links, page titles, email templates and support material. Record unresolved interface mismatches so the copy does not conceal two labels for the same feature.

Review the candidate in context

For an important page, a small decision table can keep evidence separate from taste:

Candidate	Claim and support	Editorial decision
Compare two PDF proofs in one view	Supported by the fictional packet	Keep for the product page
Find every difference	Automatic detection is not supplied	Reject
The other proof is beside this one	Supported arrangement; weak standalone topic	Consider for a caption
Finish reviews in half the time	No measurement supplied	Reject

Then read the surviving candidates aloud. Listen for the point of emphasis, missing articles and a rhythm that sounds forced. Read them quietly too. The line should remain intelligible when nobody performs it.

Ask what the reader knows after reading the line, what the page must now supply and which condition could change the decision. Check the candidate with its image and deck, then in each intended standalone use. A literal paraphrase can reveal whether the charm changed the claim.

Reader testing, where available, can add evidence about understanding and interest. Compare supported candidates and report what the test actually measures. More clicks alone do not show that readers understood the offer or completed the intended task.

Practice a different subject

Use this fictional packet:

• A layout app displays three chosen color variants of the same layout together.
• Changing one variant's color leaves the other two colors unchanged.
• No print prediction, palette recommendation or export behavior is supplied.

Write a literal headline, a headline that begins with the reader's task and a headline that draws attention to the visible arrangement. Pair each with a deck that adds a useful fact. Choose one for a product page and explain the choice without using punchy, engaging or better as the explanation.

For example:

Headline: See three color variants together

Deck: Keep the layout in view while you compare its colors. Adjust one variant's color and leave the other two as they are.

The heading names the useful arrangement. The deck moves from looking to adjusting, so its second sentence advances the work instead of praising the first. “Choose the perfect palette” would introduce a judgment the packet does not support. The plainer pair leaves room for the reader's own preference.

Now give the chosen line a second pass. Move its most useful detail to the position where it receives the right emphasis. Read the pair aloud; a longer deck may explain the relationship more naturally than three fragments. Remove any ornamental turn that makes the reader reconstruct the subject.

Finally, write the link text someone will encounter without the image. Check that it still leads to the same promise. A good short line leaves something worth reading next.