NewA human UX report in 24 hours.
Skip to content

Problem Sections That Set Up a Before and After (36)

The before/after setup frames the old, messy way of working so the product's fix lands as a clear contrast the moment a visitor reads it.

Key takeaways

  • Make the before concrete: name the real tools, hours, and workarounds.
  • Point the after at the same pain, so the contrast is one to one.
  • Close on a bridge line that turns the page toward the fix.

Showing 1–21 of 36 examples

Nautis Problem
Problem|

Nautis Productivity Problem Design

Prodpad Problem
Problem|

Prodpad Product Management Problem Design

UserEvidence Problem
Problem|

UserEvidence SaaS Problem Design

Lokalise Problem
Problem|

Lokalise Developer Tools Problem Design

Payaca Problem
Problem|

Payaca Construction Problem Design

SocialEcho Problem
Problem|

SocialEcho Social Media Problem Design

Saleshandy Problem
Problem|

Saleshandy Lead Generation Problem Design

SignOnSite Problem
Problem|

SignOnSite SaaS Problem Design

Omnibound Problem
Problem|

Omnibound AI Problem Design

Altura Problem
Problem|

Altura AI Problem Design

Process Problem
Problem|

Process Operations Problem Design

Oneflow Problem
Problem|

Oneflow Legal Tech Problem Design

ClawTeams Problem
Problem|

ClawTeams Ecommerce Problem Design

Xano Problem
Problem|

Xano No-Code Problem Design

Elvin Problem
Problem|

Elvin AI Problem Design

VC Boom Problem
Problem|

VC Boom Startup Problem Design

Wiz Problem
Problem|

Wiz Cybersecurity Problem Design

ZeBeyond Problem
Problem|

ZeBeyond Software Problem Design

Waratek Problem
Problem|

Waratek Cybersecurity Problem Design

Veridas Problem
Problem|

Veridas Cybersecurity Problem Design

Sierra Interactive Problem
Problem|

Sierra Interactive SaaS Problem Design

Didn't find the problem you were looking for?

Browse every problem pattern by UX best practice.

[WHY THIS GALLERY]

BEYOND PRETTY SCREENSHOTS

SCR
[01]

Scored, Not Curated by Taste

Every problem section is scored across 5 conversion best practices. Copy the best practice stack, not the layout. See what converts and why.

DB
[02]

36+ Real SaaS Pages

Hand-picked from 650+ companies and analyzed by our AI conversion agent. Real problem sections on live landing pages. Every entry earns its spot.

VS
[03]

Benchmark Your Own Problem Section

Found a problem section you admire? Run yours through the same scoring engine. See where you stand on the same best practices, and what to fix first.

What a before/after setup actually is

A before/after setup is a problem section that describes the old, messy way of working in enough detail that the product's fix reads as a clean contrast. It spends its first half on the before, the scattered tools, the manual copying, the hours lost, so the after the product promises has something concrete to beat. The section is not there to depress the reader. It is there to name the status quo so precisely that the fix feels inevitable.

The best problem sections build the contrast in one of a few ways:

  • A named status-quo line. A single sentence that pins the old way, like Altura's "spreadsheets cannot keep up in complicated tender processes," so the reader sees their own setup on the screen.
  • A bridge line into the fix. A closing sentence that turns the page toward the solution, the way Saleshandy ends on "There is a much easier way to do this."
  • A reframe. A line that recasts the pain as fixable, like SocialEcho's "It's not a skills problem. It's a tools problem."
  • A one-to-one after. A crisp promise that answers the exact mess above it, like Payaca's "One system. One database. One source of truth."

Why it works

A product claim in a vacuum is just an adjective. "Simple," "all in one," and "fast" mean nothing until the reader has felt the opposite. The before/after setup supplies that opposite first, so by the time the product speaks, the reader is already nodding along to the pain and primed for the relief.

It also earns trust in the diagnosis. When a section describes the current mess in the reader's own words, the reader concludes that the people behind the product actually understand the job. A fix offered by someone who clearly gets the problem is far easier to believe than a fix that arrives cold, ahead of any evidence the problem was understood.

How the best problem sections do it

Across the scored examples below, the strongest before/after setups make the before specific and the after tight. Lokalise splits its section into two current setups and defuses the pain with a subhead ("Both are fixable"), so the contrast motivates instead of deflating. Omnibound sets its after directly against the alternative, framing generic AI output as slop next to content that actually fits. The move is the same shape every time: stage a concrete before, then hand over an after that answers it point for point.

The after does not have to live in the same block. Many pages let the problem section carry the before and pass the after to the feature section's before/after contrast, or you can browse the full problem section gallery to see the range of setups.

Nautis hero section100/100
Top-scored hero: Nautis

Common mistakes

GourmetPro hero section10/100
A low-scoring hero that skips this pattern: GourmetPro

The most common failure is a before that is too vague to recognize. "Managing your work is hard" describes no one's Tuesday, so no one leans in. The fix is specificity: name the real tools, the real hours, the real workaround, the way the best examples do. The second failure is a before with no bridge, a section that stacks up pain and then stops, leaving the reader stranded in the mess with no visible way out. Every strong before/after setup closes on a line that turns the page toward the fix.

Gabriel Amzallag

Curated by

Gabriel Amzallag , Founder, Web Anatomy

5 years CRO + SEO at Qonto (2021–2025). After advising 15+ SaaS on their websites (Payfit, Pigment…), the same patterns kept breaking, so I decided to build the source of truth on what works on the web: the intelligence layer every tool, builder, and team uses to ship sites that perform.

Does your problem section set up the fix?

Paste your URL. Get a scored analysis of your problem section, including whether the before is concrete enough to make the after land. Free, no signup.

FAQ

The before/after setup, answered

The common questions about staging the before so the after lands, with answers drawn from 36 scored examples.

What is a before/after setup in a problem section?

01

It is a problem section that describes the old, messy way of working in detail so the product's fix reads as a clear contrast. The section stages the before, the scattered tools and manual workarounds and wasted hours, then points to an after that answers that exact mess. Payaca does this cleanly, closing a fragmented status quo with 'One system. One database. One source of truth.'

Why does framing the before make the product land harder?

02

A product claim means little until the reader has felt the opposite. Words like 'simple' or 'all in one' only carry weight once the current mess is fresh in mind. Describing the before first also signals that the product's makers understand the job, which makes the fix easier to believe than one that arrives cold.

How specific should the before be?

03

As specific as the reader's real week. A vague line like 'managing work is hard' recognizes no one; a concrete one names the actual tools, hours, and workarounds. Altura pins its before on 'spreadsheets cannot keep up in complicated tender processes,' so bid and tender teams see their own setup on the screen.

What is the difference between a before/after setup and just listing pains?

04

A plain pain list stops at the problem. A before/after setup adds the turn: a bridge line or a tight promise that points from the mess to the fix. Saleshandy ends its pain stack on 'There is a much easier way to do this,' which pulls the eye down toward the solution instead of leaving the reader stuck in the mess.

Where should the before/after setup sit on the page?

05

Right before the section that carries the solution, usually the features or how-it-works block. The problem section stages the before and hands off the after, so the two read as one continuous argument. Some pages keep both halves inside the problem section itself, closing on a reframe like SocialEcho's 'It's not a skills problem. It's a tools problem.'