Ed Umbao
Ed's Lab Benefit Headline Creator

Public tool / Learning project

Benefit Headline Creator

I built this after repeatedly seeing website headlines that sounded polished but did not explain clearly what the visitor could do or what they would get.

The tool turns a simple action-benefit framework into a browser workflow for generating headline options with audience, offer, proof, friction, and tone as supporting inputs.

Open live tool ↗ View GitHub ↗
Status Working learning project

Public and functional, with small usability improvements still planned.

Built with HTML · CSS · JavaScript

Published through GitHub Pages with no backend or login system.

Focus Landing-page headline clarity

Turning a repeated copywriting exercise into a small browser tool.

Turn an action-benefit headline exercise into a repeatable tool.

I wanted a faster way to work through a headline rewrite without jumping straight to clever wording. The tool starts by asking what the visitor should do and what benefit they should get.

It then adds supporting context such as the audience, offer, proof, friction removed, and tone before generating several headline options that can be reviewed and rewritten further.

01 Action

Define the thing the visitor should be able to do.

02 Benefit

Clarify the result or improvement the visitor should get.

03 Specificity

Add proof, a timeframe, a number, or friction removed where useful.

04 Variations

Generate several headline patterns to use as starting points.

Clearer headlines usually start with clearer inputs.

In copywriting work, a headline can fail because the offer itself has not been reduced to a clear action and outcome. I wanted the tool to make those inputs visible instead of only asking for the old headline.

This gave me a way to turn a copywriting principle into something interactive while also practicing front-end logic, GitHub Pages, browser behavior, and technical documentation.

A lightweight static tool was enough for the first version.

The current version can collect the inputs, clean some common phrasing, generate eight headline options, load a sample, copy the output, and reset the form without a backend or external API.

I also added simple input-cleaning functions so phrases like “the visitor should...” or “use the tool to...” do not automatically carry into every generated headline pattern.

Eight variations

The output gives me several patterns to compare instead of treating one generated line as the final answer.

Input cleanup

Small text-cleaning rules make the output less dependent on how someone phrases the form inputs.

Example loader

A sample makes the workflow easier to understand without reading detailed setup instructions.

No backend

The first version stays simple because the workflow does not need accounts, databases, or server-side processing.

More interface did not always make the tool more useful.

The first version had a large sharing widget with many destination options. It worked, but it distracted from the main job of the page: generate and copy headline ideas.

I later reduced that to a simple Copy tool link action and kept the core workflow focused on the form itself.

The original repository also had no README, so someone looking at the code could not easily tell why the tool existed, what it was meant to do, or where its limits were.

Small input rules can matter as much as adding more features.

The headline patterns depend heavily on the phrases someone enters, so even basic cleanup functions improve the result. That made me think more about input design instead of treating the interface as a set of empty text boxes.

I also learned that documenting the boundaries of a tool matters. This project does not test conversions, analyze a live landing page, validate claims, or guarantee that a generated headline will perform.

The project connects copywriting decisions with a technical workflow.

Copywriting

The tool starts with clarity: action, benefit, proof, friction, and tone before trying to create headline options.

Product content

It pushes me to describe what the visitor can actually do and what outcome the product or service supports.

Technical writing

The README and build notes explain the scope, setup, behavior, and limitations of the tool alongside the code.

Front-end learning

I practiced form handling, string cleanup, clipboard behavior, theme switching, and responsive UI in a project tied to real work.

Keep improving clarity instead of adding features for appearance.

I want future changes to improve the core headline workflow rather than make the project look larger than it needs to be.

  1. Review which generated headline patterns are actually the most useful.
  2. Improve the examples so different types of offers are easier to test.
  3. Keep the README and build notes aligned with the live tool.
  4. Consider simple analytics later if I need better evidence of how the tool is used.

I built this because headline clarity is a repeated writing problem. Turning that problem into a small tool gave me a practical way to connect copywriting, front-end code, and documentation.

Open the tool ↗ View source on GitHub ↗