Eyes don't read screens in order — they scan in predictable shapes, and those shapes depend on how much text is on the page. Text-dense screens get an F-pattern scan; sparse landing screens get a Z-pattern scan. Placing your headline, CTA, or key data point outside that path means most visitors never see it, no matter how balanced the layout looks.
Quick Answer: Use an
F-patternlayout for text-heavy pages (docs, dashboards, articles) — put the critical message in the first two horizontal sweeps, left-aligned. Use aZ-patternfor sparse landing screens — put your primary CTA at the bottom-right or top-right, the two points eyes actually land on.
Why Scanning Behavior Should Drive Placement, Not Aesthetic Balance
Most wireframes get laid out for visual symmetry first and scanning behavior second — that's backwards. Eye-tracking research going back two decades shows people don't read web pages the way they read a printed page top to bottom. They scan in a handful of repeatable shapes, and a layout that looks "balanced" to a designer's eye can still bury the one element that needed to be seen.
This matters because a wireframe is a hypothesis about attention, not just a hypothesis about content. When a PM sketches where a CTA or a key stat goes, they're implicitly betting on where a visitor's eyes will actually travel. Get the bet wrong and the layout can be pixel-perfect and still convert badly.
The Research Behind the Patterns
Three separate bodies of eye-tracking work converge on the same conclusion: attention is not evenly distributed across a screen, and it follows a small number of recognizable shapes.
- Nielsen Norman Group's F-shaped pattern study (Jakob Nielsen, originally 2006, revisited in later NN/g eye-tracking work) recorded gaze paths across dozens of websites and found reading behavior clustered into a fluent top-heavy, left-weighted shape — an F. Their broader eye-tracking corpus put average word-level reading at well under a third of on-page text, often closer to one word in five, meaning most content on a dense page is scanned, not read.
- Poynter Institute's Eyetrack III research on news sites found headlines pulled first fixations more consistently than photos across most tested layouts — a direct challenge to the assumption that a hero image is always the strongest attention magnet.
- Enquiro/Mediative's "Golden Triangle" eye-tracking study of search results pages found fixations concentrated overwhelmingly in the upper-left triangle of the results, thinning sharply moving right and down the page.
Why Aesthetic Balance Fights Reading Behavior
A symmetrical, centered layout distributes visual weight evenly across the frame. Real attention doesn't distribute evenly — it front-loads toward the top-left and decays as it moves right and down. A layout optimized for symmetry actively fights the eye's natural path, spending equal design effort on zones that get a fraction of the fixations.
This is the core reframe this article makes: layout decisions belong in the wireframe, not just the visual polish pass. If you're still deciding whether a placement question needs a wireframe at all or can be resolved in a written spec, when a PM should wireframe versus write it up is the relevant call to make first — scan-path questions are squarely wireframe territory, because they're spatial by nature.
The F-Pattern: Placing Content on Text-Dense Pages
On text-dense screens, eyes trace a shape that looks like the letter F: a long horizontal sweep at the top, a shorter one below it, then a vertical drift down the left edge. Put your most important sentence in the first sweep and your second-most-important point in the second — anything relying on the reader reaching the right side of line four is a bet against the data.
The F-pattern shows up on pages with real reading load: articles, documentation, dashboards, search results, long product pages. It's a fluency pattern — readers spend real effort at the top, then increasingly sample rather than read as they move down, using the left edge as an index of "is this section relevant to me."
| Scan Zone | Where It Sits | What Eyes Actually Do | What to Place There |
|---|---|---|---|
| First horizontal sweep | Top of the content block, full width | Longest, most complete read | Headline, thesis sentence, key number |
| Second horizontal sweep | Mid-page, noticeably shorter | Partial read, more skipping | Subhead, first supporting claim, primary CTA |
| Left-edge vertical drift | Down the left margin | Fast scan for anchor words | Section labels, bolded lead words, nav |
| Lower-right region | Bottom right of the block | Rarely reached without a deliberate scroll | Secondary detail, footnotes, low-priority links |
Designing for the Sweep, Not the Sentence
Three practical moves follow directly from the shape:
- Front-load the sentence, not just the paragraph. Put the conclusion in the first six to eight words of a heading or lead line — the part most likely to fall inside the first sweep.
- Use the left edge as a real information channel. Bold lead words, consistent labels, and left-aligned icons all ride the vertical drift; centered text has no left edge for the eye to anchor on.
- Treat everything past the second sweep as optional. If a reader only gets two sweeps' worth of attention, the third sweep's content should be able to be skipped without losing the page's core message.
If you're translating these zones into actual wireframe elements — header blocks, sidebar blocks, content blocks — the shared vocabulary for wireframe layout blocks keeps that translation consistent across a team, so "put it in the second sweep" maps to the same block every time instead of a fresh argument per screen.
The Z-Pattern: Placing Content on Sparse Landing Screens
On sparse landing screens with little text, eyes trace a Z: top-left to top-right, diagonally down to bottom-left, then across to bottom-right. The two corners where the diagonal sweep starts and ends — top-left and bottom-right — get disproportionate attention, which is exactly why bottom-right is the classic "primary CTA" position in marketing layouts.
The Z-pattern applies where the F-pattern doesn't: hero sections, pricing pages, single-message landing pages, app onboarding screens — anywhere there's more white space than text and a single dominant message rather than a body of content to read through.
| Dimension | F-Pattern | Z-Pattern |
|---|---|---|
| Best for | Text-dense pages: articles, docs, dashboards, search results | Sparse pages: hero sections, landing pages, pricing screens |
| Content volume | High word count, multiple sections | Low word count, one dominant message |
| Eye movement shape | Repeated horizontal sweeps, decreasing width, left-edge drift | One diagonal sweep connecting four corner stops |
| Primary CTA placement | End of the first or second sweep, left-aligned | Bottom-right or top-right — the Z's terminal points |
| Typical wireframe block | Content block plus sidebar block | Hero block plus a single, isolated CTA block |
Why the Diagonal Matters More Than the Center
A landing page built around a centered hero image with the CTA underneath is optimizing for symmetry, not for the Z. The diagonal stroke of the Z is the weakest part of the scan — it's a transit, not a stopping point — so content placed dead-center in the middle of the page, where the diagonal passes through, gets less genuine attention than either corner.
This is the same reframe as the F-pattern section, applied to a different content shape: a landing screen is usually the entry point of a much longer arc a visitor is on. If you're mapping how that arc unfolds after the first screen, the customer journey emotion curve is worth cross-referencing — a Z-pattern landing screen is one moment in that curve, not the whole story.
Top-Left Primacy: Why LTR Interfaces Favor the Upper-Left Corner
In left-to-right reading cultures, the top-left corner of a screen gets the first fixation and the most return visits — a concept designer Edmund Arnold called "reading gravity" in his Gutenberg diagram. That single fact underlies both patterns above: the F starts top-left, and the Z starts there too. Anything placed there inherits attention it didn't have to earn.
Arnold's diagram, developed for newspaper layout long before web design existed, divides a page into four zones by attention weight. It still holds up in digital eye-tracking studies because the underlying cause — the direction a culture reads text — hasn't changed.
| Quadrant | Arnold's Name | Relative Attention | What Typically Goes There |
|---|---|---|---|
| Top-left | Primary optical area | Highest — first fixation | Logo, headline, core value statement |
| Top-right | Strong fallow area | Second-highest | Nav CTA, sign-up or trial button |
| Bottom-left | Weak fallow area | Lowest — often skipped entirely | Secondary links, legal text, low-priority content |
| Bottom-right | Terminal area | Second-highest — a resting point | Primary CTA, closing statement |
What This Means for Wireframe Decisions
The practical rule is blunt: never put your single most important element in the bottom-left quadrant. It's the weakest of the four zones in nearly every eye-tracking study of LTR layouts, yet it's a common dumping ground for "secondary" navigation or footer content that quietly turns out to matter.
Deciding which content earns the primary optical area versus the weak fallow area is exactly the kind of call that should get made in a wireframe, before it becomes a visual-design argument. That's also where the line between a PM's layout intent and a designer's execution needs to be explicit — the handoff line between PM sketches and designer polish is worth setting early so "this goes top-left" survives the handoff instead of getting silently reshuffled for symmetry.
Note the caveat: this entire section flips for RTL languages (Arabic, Hebrew). Reading gravity follows the writing direction, so a Gutenberg diagram for a Hebrew-language product should mirror the zones horizontally — primary optical area top-right, terminal area bottom-left.
Annotated Example: Moving a Misplaced CTA Into the Scan Path
A CTA placed in a low-attention zone underperforms even when the copy, offer, and design are all correct — because most visitors' eyes never fixate there long enough to register it. The fix is rarely better copy; it's almost always relocation into the scan path the layout already produces.
Take a common pattern-mismatch: a pricing page with a centered hero, a large illustration filling the top half, and the "Start free trial" button centered below the fold, under the illustration.
Before: CTA Outside the Scan Path
- Illustration occupies the primary optical area (top-left through top-right) — it wins the first fixation, but it's decorative, not actionable.
- Headline is centered, splitting attention across both weak zones instead of anchoring in one strong one.
- CTA sits bottom-center, straddling the boundary between the weak fallow area and the terminal area — neither zone fully claims it.
- Pricing detail runs in a dense paragraph below the CTA, in the least-scanned region of the page.
After: CTA Repositioned Along the Z
- Move the headline to top-left, replacing the illustration's claim on the primary optical area with the actual value statement.
- Move the illustration to top-right or shrink it — it becomes supporting evidence in the strong fallow area, not the first thing competing for attention.
- Place the CTA at bottom-right, the Z's terminal point, instead of bottom-center — it now sits inside a naturally high-attention zone rather than between two zones.
- Convert the pricing paragraph into a short comparison table near the CTA, so the last thing scanned before the terminal area is scannable, not a wall of text.
The underlying question this exercise answers isn't "where does the CTA look nice" — it's "what job is a visitor trying to get done on this screen, and does the CTA sit where that job's decision actually happens." Anchoring placement to the job the visitor is hiring the page to do keeps the reposition from becoming a cosmetic tweak; it ties the move to behavior, not taste.
Turning Scan Patterns Into a Wireframe Checklist
Scan-pattern placement becomes a repeatable wireframe habit once it's a checklist, not a one-off analysis. Run through these questions before a layout goes from sketch to hand-off, and revisit them any time a screen's content density changes enough to shift it from one pattern to the other.
- Classify the screen first. Is this text-dense (F-pattern) or sparse with one dominant message (Z-pattern)? Don't apply F-pattern rules to a hero screen or Z-pattern rules to a documentation page — the wrong pattern misdirects the whole layout.
- Identify the single most important element. One headline, one CTA, one number — pick it before laying out anything else, so there's something to protect from drifting into a weak zone.
- Place it in the primary optical area or a terminal point. Top-left for the opening claim; bottom-right (Z) or the end of the second sweep (F) for the action you want taken.
- Audit the bottom-left quadrant. Whatever's there, confirm it's genuinely low-priority — this is where important content accidentally hides most often.
- Check left-edge legibility on F-pattern screens. Bolded lead words and consistent labels should be scannable down the margin without reading full sentences.
- Test with a five-second look, not a full read. Cover the wireframe, reveal it for five seconds, ask what was noticed first — a rough but genuinely useful proxy for where the primary optical area actually fell.
For the broader discipline this checklist sits inside — including where wireframing fits relative to other product artifacts — the complete guide to wireframing covers the full workflow this article assumes.
Where Prodinja Fits
This is exactly the kind of spatial decision that's hard to make well in a written spec and easy to get wrong by eye in a general-purpose design tool with no scan-path guidance built in. Prodinja's Wireframing composer lets you position blocks — hero, nav, content, CTA — along the natural scan path for the screen type you're building, so the block you mark as primary lands in the zone attention actually reaches, rather than wherever the grid happened to have empty space.
Key Takeaways
- Layout should follow reading behavior, not visual balance — a symmetrical wireframe can still bury its most important element in a low-attention zone.
- Use the F-pattern for text-dense screens: front-load the first two horizontal sweeps and the left-edge vertical drift; treat anything past that as optional.
- Use the Z-pattern for sparse landing screens: anchor content at the four corners the diagonal sweep connects, especially top-left and bottom-right.
- Top-left is the primary optical area in LTR interfaces — per Edmund Arnold's Gutenberg diagram, it earns attention it hasn't yet had to justify; this flips entirely for RTL languages.
- A misplaced CTA is usually a placement problem, not a copy problem — relocating it into the scan path often matters more than rewriting it.
- Classify the screen before laying it out: text-dense and sparse screens need different patterns, and applying the wrong one misdirects the whole layout.
- A five-second look test is a cheap, genuinely useful proxy for checking where a wireframe's primary optical area actually falls before it ships.
Frequently Asked Questions
Is the F-pattern still valid for modern web design in 2026?
Yes — the F-pattern describes a reading behavior tied to how humans process dense text, not a specific era of web design, so it hasn't gone stale. Nielsen Norman Group's ongoing eye-tracking work continues to find the same top-heavy, left-weighted shape on text-dense pages, including on mobile.
Should mobile screens use the F-pattern or the Z-pattern?
Use whichever pattern matches the content density, the same rule as desktop: a mobile article or dashboard still scans in an F; a mobile landing screen with one hero message still scans in a Z, just compressed vertically. Mobile's narrower viewport shortens the horizontal sweeps in both patterns but doesn't change which one applies.
Where exactly should I place my primary CTA in a wireframe?
Place it at the end of the first or second horizontal sweep on text-dense screens (F-pattern), or at the bottom-right terminal point on sparse landing screens (Z-pattern). Both positions sit inside a genuinely high-attention zone rather than a decorative or fallow one.
Does the Z-pattern apply to right-to-left (RTL) languages like Arabic or Hebrew?
The Z-pattern itself mirrors horizontally for RTL languages — the scan starts top-right instead of top-left and ends bottom-left instead of bottom-right. Reading gravity follows writing direction, so any scan-path layout needs a mirrored variant for RTL locales, not just a translated one.
How do I verify a wireframe actually follows the intended scan path?
Run a five-second look test: show the wireframe for five seconds, then ask what was noticed first and second. If the answer doesn't match the element you intended to be primary, the layout is fighting the scan pattern rather than using it, and it's worth revisiting placement before it moves to visual design.