Why We Design the Hero Section Last
Why Do We Design the Hero Section Last?
Because the hero is a summary, and you cannot summarise a page you have not written. Designing it first means committing to a promise before you know what the page can support. We build the body first, then design the hero to introduce what is actually there.
This is not how most projects run. The hero is usually the first thing anyone draws, because it is the part stakeholders can picture and the part that gets shown in the kickoff meeting. It is also the part that gets revised eleven times, and that is not a coincidence.
Here is the reasoning, including the parts where the conventional order is defensible.
What Goes Wrong When the Hero Comes First?
The page gets built to justify a headline nobody has tested. Somebody writes a strong sounding line in week one, everyone approves it, and then the rest of the page spends its life trying to make that claim true. When the evidence turns out to be thinner than the promise, the page reads as overreach.
The second failure is layout lock in. A hero with a large image on the right sets a rhythm, and every section after it is either obedient to that rhythm or fighting it. That decision deserves to be made with knowledge of what the page contains, not before.
The third is the revision cycle. Every stakeholder has an opinion about the hero and nobody has an opinion about the fourth section. Starting there means starting your most contested conversation with the least information, which is a reliable way to spend three weeks.
Does the Hero Actually Matter as Much as People Think?
It matters a lot, and slightly less than it used to. Nielsen Norman Group's eye tracking research, based on "over 130,000 eye fixations on a 1920x1080 screen" from "120 participants", found that "users spent about 57% of their page-viewing time above the fold." In its 2010 study "80% of the viewing time was made up of fixations above the fold."
The concentration is still striking. The same research reports that "more than 42% of the viewing time fell within the top 20% of the page, and more than 65% of the time was spent in the top 40% of the page." It also found that "74% of the viewing time was spent in the first two screenfuls" and that people "rarely go beyond the third screenful of info."
Read that fairly and it supports both arguments. The top of the page carries most of the attention, so it had better be right. And 43% of attention is now below the fold, which is far more than the old folklore allowed, so the body is not a place to be careless.
So Why Not Just Design the Most Important Thing First?
Because importance and sequence are different questions. The foundations of a building matter less to the people using it than the entrance, and they still get built first. The hero depends on the page. The page does not depend on the hero.
Working body first also changes the conversation with clients in a useful way. When you present section four before the hero, the discussion is about whether the argument holds. When you present the hero first, the discussion is about the photograph.
We are not claiming this is the only workable order. Plenty of good studios work the other way and produce excellent sites. We are claiming that the order changes which conversations you have and when, and that having the evidence conversation earlier is worth a lot.
What Does Body First Actually Look Like?
You start with the argument, in plain text, with no layout at all. What does this page need the reader to believe, in what order, and what evidence supports each step. That document is usually a page long and it is the real design work.
Then you build the sections that carry the evidence. Proof, comparison, objection handling, whatever the argument requires. By the time those exist, you know what the page can honestly claim, and the hero almost writes itself because it is a compression of something real.
The hero design comes last and takes less time than it would have taken first. There is less to argue about, because the alternative headlines can be checked against what the page actually delivers.
How Does This Affect Performance?
It makes the performance conversation possible while the decision is still cheap. The hero is usually the Largest Contentful Paint element, and LCP is one of the Core Web Vitals. Google's guidance is that "a good LCP value is 2.5 seconds or less", measured at "the 75th percentile of page loads, segmented across mobile and desktop devices", with values above 4.0 seconds classed as poor.
The LCP candidates are worth knowing when you are choosing a hero treatment. Google lists image elements, image elements inside an SVG, video elements, elements with background images set using url(), and "block-level elements containing text nodes or other inline-level text element children." A text hero can be the LCP element too, and it is usually the fastest kind.
Deciding the hero last means the budget is already known. You have built the page, you know what it weighs, and you can pick a hero treatment that fits rather than discovering in week six that the full width video you promised costs you the metric. We went deeper into the mechanics in our piece on Largest Contentful Paint.
When Would We Design the Hero First Anyway?
When the hero is the product. A brand campaign page, a launch announcement, or anything where the image is the message is a different job, and pretending otherwise is just dogma. In those cases the hero is not a summary of the page, it is the page.
The second case is when the client needs to see the direction before they can approve anything else. That is a real constraint and not an unreasonable one. When it applies, we will produce a hero direction early, and we say clearly that it is a direction rather than a decision.
The third is a redesign where the hero is the only thing changing. Obviously you start there. The principle is about new pages where the argument is not yet settled, not about every task that touches a hero.
What Should the Hero Actually Contain?
One claim, one qualifier, one action, and enough context to tell a stranger what this is. Most weak heroes fail on the last of those. They are evocative and they never say what the company does, which means a visitor has to scroll to answer the question that brought them.
The claim should be the strongest thing the page can actually prove. If the body has a comparison table, the hero can be pointed. If the body is a general explainer, a pointed hero is writing a cheque the page cannot cash.
Keep the action singular. Two equally weighted buttons is a decision handed to the visitor that the page should have made. We wrote about the surrounding choices in our piece on hero section design.
Does This Change Anything for AI Answer Engines?
It reinforces it. Retrieval systems lift passages from the body of a page, and a hero image is invisible to them. A page whose substance lives in its sections is legible to a machine in a way that a page carried by a striking hero is not.
That is an argument for the body being genuinely good rather than for the hero being weak. But when a team has a fixed amount of design and writing effort, the traditional order tends to spend it at the top, and the sections that get quoted are the ones that were rushed.
The same content that makes a page quotable makes it convincing to a human who scrolled. That 43% of attention below the fold and the passage a retrieval system lifts are looking at the same material.
How Do You Introduce This to a Team That Works the Other Way?
Do not announce a new process. Just write the argument document before the first design review and bring it. Most of the value arrives at that point, because the conversation shifts from what the page should look like to what it needs to say.
Then present one body section alongside the hero concepts rather than instead of them. Seeing them together makes the dependency obvious without anybody having to argue for it in the abstract, and people usually reach the conclusion themselves.
If you want to talk through how we would sequence a page like this, or you have a hero that has been through nine rounds and is not getting better, we are happy to help. Find us at phoenix.studio.
Want a site that performs like this?
Tell us about your project. We will come back with a clear next step, no pressure.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Have a project like this?
Tell us where you want to go. We'll tell you how we'd get you there.