---
name: use-case-page-design
slug: use-case-page-design
description: This skill should be used when the user asks to "design a use case page", "create use case landing pages", "write a use case page for SaaS", "design solution pages", "build industry-specific landing pages", "create persona-specific pages", "design use case pages for SEO", "write solution landing pages", "build use case content", or any variation of designing use case or solution landing pages for B2B SaaS.
category: general
---

# Use Case Page Design

A use case page shows a specific audience how your product solves their specific problem. Not a feature page (what the product does). Not a homepage (what the company does). A use case page answers: "How does [product] help [persona] solve [problem]?"

The principle: every use case page serves one audience with one problem. "For Sales Teams" is too broad. "Pipeline Reporting for VP Sales" is focused enough to rank, convert, and resonate. The narrower the use case, the higher the conversion rate.

## Page Architecture

### Use case taxonomy

```
/use-cases/                          → Hub listing all use cases
/use-cases/[persona]/                → Persona-level page
/use-cases/[persona]/[problem]/      → Specific use case page

Examples:
/use-cases/sales-leaders/            → "For Sales Leaders"
/use-cases/sales-leaders/pipeline-reporting/  → specific use case
/use-cases/revops/                   → "For RevOps"
/use-cases/revops/lead-routing/      → specific use case
```

### Architecture options

| Structure | When to use | Example |
|-----------|------------|---------|
| By persona | When different roles use the product differently | /use-cases/sales-leaders/, /use-cases/marketers/ |
| By problem | When the same role has distinct problems you solve | /use-cases/pipeline-reporting/, /use-cases/lead-routing/ |
| By industry | When your product serves multiple verticals | /use-cases/fintech/, /use-cases/healthcare/ |
| By company stage | When stage determines the use case | /use-cases/startups/, /use-cases/enterprise/ |

---

## Page Structure

### The use case page template

| Section | Content | Word count |
|---------|---------|-----------|
| Hero | Headline + subhead + primary CTA | 30-50 words |
| Problem statement | The specific problem this audience faces | 100-150 words |
| Solution overview | How your product solves it (3-4 key capabilities) | 150-200 words |
| Feature highlights | 3-4 features with screenshots and brief descriptions | 200-300 words |
| Social proof | Customer quote, logo, or case study from this use case | 50-100 words |
| How it works | 3-step process or workflow | 100-150 words |
| Results/outcomes | Specific metrics or outcomes from this use case | 50-100 words |
| CTA | Demo request or free trial, specific to this audience | 20-30 words |
| FAQ | 3-5 questions this persona would ask | 150-200 words |

### Section rules

- **Problem before solution.** The reader needs to feel understood before hearing how you help. Lead with the problem in their language. "Spending 3 hours every Monday building pipeline reports manually?" before "Automated pipeline reporting"
- **Use the persona's language.** A VP of Sales says "pipeline visibility." A RevOps leader says "data hygiene." An SDR says "more meetings." Mirror their vocabulary on their page
- **3-4 features max.** This is not a feature page. Highlight only the 3-4 capabilities that matter most for this specific use case. Link to the full feature page for the rest
- **One customer story from this exact use case.** A testimonial from a VP Sales on the VP Sales use case page. Not a generic "Our customers love us" quote. Specific persona, specific use case
- **CTA matches the use case.** "See how [product] helps sales leaders with pipeline reporting" not "Request a demo." The CTA should reflect the page's specific context

---

## Writing the Hero Section

### Headline formula

```
[Outcome] for [Persona]

Examples:
"Pipeline Visibility for Sales Leaders"
"Lead Routing That Actually Works for RevOps"
"Outbound at Scale for SDR Teams"
"Enterprise Account Intelligence for ABM Teams"
```

### Hero rules

- **Persona in the headline.** The reader should see themselves in the first 5 words. "For Sales Leaders" or "For RevOps Teams" confirms they're in the right place
- **Outcome, not feature.** "Pipeline Visibility" not "Pipeline Dashboard." "Outbound at Scale" not "Email Sequencing Tool." The outcome is what they care about
- **Subhead adds specificity.** Headline: "Pipeline Visibility for Sales Leaders." Subhead: "Know exactly where every deal stands. No more Monday morning CRM archaeology."
- **Primary CTA above the fold.** "See it in action" or "Start free trial" visible without scrolling

---

## Writing the Problem Statement

### Problem statement formula

```
[Persona] struggles with [specific problem].
[Concrete consequence of the problem].
[What they currently do as a workaround].
[Why the workaround doesn't work].
```

### Example

```
VP Sales spends 3 hours every Monday pulling pipeline
data from Salesforce into a spreadsheet. The numbers
are already stale by Tuesday. Reps update deals
inconsistently, so the forecast is more fiction than
fact. The board wants accurate numbers. You're
guessing and hoping nobody checks.
```

### Problem rules

- **Be specific about the pain.** "Sales is hard" is generic. "You have 47 open deals and no idea which 10 will actually close this quarter" is specific
- **Name the workaround.** "You're manually exporting to Excel every Monday" shows you understand their current process. It builds credibility
- **Quantify the cost.** "3 hours per week on manual reporting = 150 hours per year = 4 weeks of a VP's time." Numbers make the pain concrete
- **No fear-mongering.** State the problem factually. Don't exaggerate. Readers who recognize the problem will convert. Readers who feel manipulated will bounce

---

## Social Proof on Use Case Pages

### What to include

| Proof type | Best for | Example |
|-----------|---------|---------|
| Customer quote from this persona | Building trust with the specific audience | VP Sales at a Series B SaaS: "We went from guessing to knowing" |
| Logo wall of companies using this use case | Showing adoption breadth | 5-8 logos of companies who use the product for this specific use case |
| Metric from this use case | Proving outcomes | "42% reduction in forecast variance" |
| Mini case study | Providing detailed evidence | 3-sentence summary: problem, solution, result for one customer |

### Social proof rules

- **Match the proof to the persona.** A VP Sales quote on the VP Sales page. Not a marketing manager quote. Persona mismatch kills credibility
- **Specific outcomes beat generic praise.** "Reduced forecast variance by 42%" beats "Great product, highly recommend." Numbers are more persuasive than adjectives
- **Real names and titles.** "Sarah Chen, VP Sales at Ramp" beats "VP Sales at a fast-growing SaaS." Real names signal real testimonials
- **If you don't have persona-specific proof, skip the section.** A generic quote is worse than no quote. It signals you couldn't find someone in this role who would vouch for this use case

---

## SEO for Use Case Pages

### Keyword targeting

| Query pattern | Example | Volume |
|-------------|---------|--------|
| [product] for [persona] | "CRM for sales leaders" | Medium (500-2K/mo) |
| [product] for [industry] | "CRM for fintech" | Medium (200-1K/mo) |
| [problem] software | "pipeline reporting software" | High (1K-5K/mo) |
| [problem] tool | "lead routing tool" | Medium (500-2K/mo) |
| best [product] for [use case] | "best CRM for startups" | High (2K-10K/mo) |

### SEO rules

- **One primary keyword per use case page.** "pipeline reporting for sales leaders" is one keyword cluster. Target it with one page. Don't split across multiple pages
- **Internal link from homepage.** Use case pages should be linked from the homepage navigation or a prominent "Use Cases" section. This signals importance to Google
- **Internal link from blog content.** Blog posts about pipeline reporting should link to the pipeline reporting use case page. This builds topical authority
- **Don't cannibalize your feature pages.** If /features/pipeline-dashboard/ targets "pipeline reporting" and /use-cases/sales-leaders/pipeline-reporting/ also targets it, they compete. Differentiate the target keywords

---

## Measurement

| Metric | Definition | Target | Frequency |
|--------|-----------|--------|-----------|
| Organic traffic | Monthly visits per use case page | Growing month-over-month | Monthly |
| Conversion rate | Demo requests or sign-ups per page | 3-8% | Monthly |
| Bounce rate | % leaving without action | < 60% | Monthly |
| Time on page | Average engagement | > 2 minutes | Monthly |
| Search ranking | Position for primary keyword | Top 10 | Weekly |
| Pipeline attributed | Pipeline from use case page visits | Track trend | Quarterly |

---

## Pre-Publish Checklist

- [ ] Headline includes persona and outcome (not just features)
- [ ] Problem statement names the specific pain and current workaround
- [ ] Solution section highlights 3-4 features most relevant to this use case
- [ ] Social proof is from the same persona/industry as the page
- [ ] CTA is contextual to the use case (not generic "request a demo")
- [ ] Page linked from homepage or main navigation
- [ ] FAQ section addresses 3-5 persona-specific questions
- [ ] Screenshots show the product being used for this specific use case
- [ ] Internal links from related blog content and other use case pages
- [ ] Primary keyword targeted in H1, meta title, and URL
- [ ] Page loads in under 2 seconds

---

## Anti-Pattern Check

- Use case page is just a feature page with a different URL. Listing 12 features is a feature page. Showing how 3-4 features solve a specific persona's problem is a use case page. Lead with the problem, not the feature list
- "For Everyone" page. A use case page that tries to serve sales, marketing, RevOps, and CS simultaneously. It resonates with nobody. One persona, one problem, one page
- No social proof from the target persona. VP Sales page has a quote from a marketing manager. Persona mismatch. Either find a matching testimonial or skip the section entirely
- Generic CTA. "Request a demo" on every page. The use case page CTA should reflect the page context: "See how [product] handles pipeline reporting for your team"
- Use case pages not linked from anywhere. Five use case pages exist but they're not in the navigation, not linked from the homepage, and not linked from blog posts. They're orphaned. Google won't find them
- Too many use case pages, all thin. 20 use case pages with 200 words each. None rank. Better to have 5 deep, well-crafted pages that rank than 20 thin pages that don't. Start with your top 5 use cases
- Problem statement missing entirely. The page jumps straight to features. The reader doesn't feel understood. They bounce. Always lead with the problem before presenting the solution