How to Write Benefit Sections

At her desk, Ottoline has three empty boxes on her laptop, headed "Save time," "Reduce stress" and "Grow your business." Above the screen hangs a poster printed from the second-to-last artwork file, with the old date still in the corner.

We'll use Ottoline and Acornspool Approvals as an invented example. She's writing a page for a tool that keeps comments beside artwork and lets a project owner mark a version approved.

The poster gives her an obvious promise: prevent another printing mistake. Before she fills those boxes, she needs to work out how much of that promise the tool can keep.

Begin with a job someone is trying to finish

Ottoline writes down the job: a designer needs to identify the approved artwork before sending it to print. That gives her a decision to help with, and a product record she can show.

You'd choose that job from customer research. Copyhackers' research guidance recommends recording what people want and find difficult before drafting; keep those sources beside your proposed benefits.

A product team's belief about what customers value stays labelled as a hypothesis until better evidence turns up. If the brief only said "designers want less stress," Ottoline would still need to find out which part of sending artwork causes trouble.

In this example, the brief says designers struggle to identify the approved version. Ottoline puts that problem first and leaves the broader claim about growing a business out of the draft.

"Keep every file organized" may be true as well. It could describe almost any tool, while the approval benefit connects to the decision that brought this visitor to the page.

One hypothetical feature, developed into a section

1. Capability

   A project owner can mark a specific artwork version approved.

2. Practical consequence

   The team can identify the version the project owner approved.

3. Section headline

   Know which artwork is approved before you send it onward.

4. Supporting evidence

   Show a version record with approval status and explain who can change it.

Build the chain from feature to consequence

For each feature, ask what changes for someone doing that job. The features-versus-benefits lesson explains the distinction; here you need enough detail to build a whole section.

Ottoline tries "Never print the wrong artwork again." Looking at the poster, she checks what would have to happen for that to be true.

An approval mark identifies a recorded decision. Someone still has to check the artwork and send the correct file to production, so she narrows the heading to the part Acornspool controls.

CXL's product-description guidance recommends presenting features alongside benefits. Apply that here by naming the practical improvement in the heading and explaining the product behavior beneath it.

Show which version carries the approval mark.

Inspect the approval record

Compare the approved version with the earlier draft. Keep the version names visible in the evidence image so a designer can see which file each status belongs to. A detached badge leaves that question open.

The illustration shows the hypothetical approval workflow a benefit claim passes through.

Write the section as a small argument

Ottoline drafts an evidence request: a screenshot showing the approval mark next to a specific version, with earlier versions still visible in history. She'll confirm that behavior before choosing an image.

You can use a screenshot to demonstrate an interface claim. If you promise a measured result, you'll need evidence of that result; a picture of the interface won't establish it.

Her first caption, "Powerful dashboard," becomes "The approval mark beside this version records the project owner's decision." A designer now knows which part of the screenshot supports the heading.

Keep that explanation in readable text too, so the evidence doesn't depend on deciphering a small screenshot. Crop closely enough to show the version name beside its status; a detached approval badge could belong to any file.

Hypothetical copy for the approval feature

A feature with a broader promise

Manage approvals. Send the right artwork to print with confidence.

A section with a reason to believe

Know which artwork is approved. Mark the version your project owner signed off, and keep that decision beside the file. Your team can check the status before passing the artwork onward.

The revision promises a status check. Approval records show a decision; they don't establish that the artwork is ready to print.

In what order should benefits appear?

Once the approval section is drafted, Ottoline looks at the questions it leaves open. How did the feedback reach this version? What happens if the team needs to revisit earlier work?

Those questions give her an order for the remaining sections. She can explain comments alongside the artwork, then show how the version history works.

Choose your order around the visitor's task. For a designer reviewing feedback, you might lead with comments; for a project owner recording a decision, approval may deserve the first position.

Keep the intended audience next to the draft while you arrange it. The landing-page anatomy lesson shows where these sections sit within the rest of the page.

Check the product, then read for implied claims

Ottoline asks the product owner to demonstrate approval in a sample account. First, she checks whether the mark identifies a particular version and who has permission to change it.

Check any limits the demonstration reveals against the draft. If only a project owner can record approval, "anyone can approve artwork" would give visitors the wrong expectation.

Suppose the demonstration shows that an owner can change approval. Ottoline adds a question to the evidence request: does the record show the current status clearly after that change? The screenshot needs to represent the behavior she's describing.

With the behavior checked, Ottoline reads the supporting copy for a larger claim that might have slipped back in. Comments alongside artwork can help a designer find the relevant feedback; a promise of permanent peace of mind would need much more evidence.

Emotional value can still belong in the copy. "Check the recorded approval before you send the file" gives relief a cause. To publish "Experience complete confidence," Ottoline would need evidence beyond a working approval mark.

The FTC's small-business advertising FAQ says advertisers need proof for express and implied claims that consumers take from an ad. Its example sticks with me. A mouthwash ad saying it "kills the germs that cause colds" implies it will prevent colds, though the ad never says so.

Ottoline finds "Your team can stop checking files" beneath her accurate heading. A reader could take that as permission to skip the artwork check, so she deletes it. She reads the caption for the same implication before requesting the screenshot.

The FAQ addresses U.S. advertising claims. In your draft, underline words such as "never" and "guarantee" and decide what would back each one up.

Choose evidence after those checks, using the proof lesson if you need help. Keep unresolved claims marked in the draft until someone can demonstrate them.

Give related benefits different jobs

Approval status and version history share a screen, so Ottoline could easily give them nearly identical sections. She assigns each a separate reader question before writing further.

Hypothetical section openings with distinct jobs

Current decision

Know which artwork is approved.

Use this section to explain the status and who records approval.

Relevant feedback

Read comments beside the version they refer to.

Use this section to show where comments sit, and leave the approval promise to the opening.

Earlier work

Revisit the version before the last round of changes.

Use this section to demonstrate history and any access limits.

Let each section take the space its explanation needs. If your design uses equal-sized cards, adjust the layout when a capability needs more explanation or a simple one leaves empty space.

Ottoline keeps history out of the approval paragraph except where it's needed to explain the screenshot. The history section can then show what remains available and how someone retrieves it.

Turn a feature list into section cards

Make a card for each proposed section and put its reader question at the top. The Landing Pages topic can help you place the finished sections within a page.

Attach the evidence you'd need, then arrange the cards around the visitor's task. Ottoline moves the approval card first and gives the remaining cards their own questions.

Ottoline puts "Know which artwork is approved" above the screenshot. Then she opens the marked version of the next poster, reads the date in the corner and sends that file to the printer.