Documentation

Content Patterns

Narrative structures for websites, presentations, and apps.

Overview

Catalyst supports three project models, each with distinct content patterns. These patterns provide starting points—adapt them to your specific needs.

Website Narrative Pattern

Websites provide orientation, narrative, and trust. The structure leads visitors from understanding to action.

1

Hero

Clear value proposition. What is this? Why should I care?

e.g., H1 + subhead + primary CTA

2

Problem

Anchor the why. What pain does this solve?

e.g., Bullet points of current frustrations

3

Solution

How does this solve the problem? Before/after contrast.

e.g., Grid comparing old way vs new way

4

Audience

Who is this for? Help visitors self-identify.

e.g., 3 audience cards with specific benefits

5

How It Works

Simple process overview. Make it concrete.

e.g., 3-6 step flow with icons

6

Proof

Evidence it works. Testimonials, logos, case studies.

e.g., Customer quotes or project examples

7

Objections

Address concerns. FAQ or scope boundaries.

e.g., What this is NOT / limitations

8

CTA

Clear next step. Don't make them think.

e.g., Primary + secondary action buttons

Presentation Narrative Pattern

Presentations tell a stakeholder story leading to decisions. Each slide/section advances the argument.

1

Context

Where are we? What happened to get here?

e.g., Current situation, recent events

2

Challenge

What's the problem or opportunity?

e.g., Specific issue with evidence

3

Options Considered

What paths were evaluated?

e.g., 2-3 options with trade-offs

4

Recommendation

What do we propose and why?

e.g., Clear recommendation with rationale

5

Evidence

Why should we trust this recommendation?

e.g., Data, examples, expert opinion

6

Implications

What happens if we do this? If we don't?

e.g., Risks, costs, benefits

7

Next Steps

What decisions are needed? What happens next?

e.g., Specific asks with owners

App Proof Pattern

Apps demonstrate working proof with staged hardening. In POC stage, the focus is on validating the concept, not polish.

Context Switch

Every page should be able to explain why it exists and what it proves. Include a toggle or panel showing the reasoning behind the UI.

e.g., 'Why this page' button revealing Vision/Requirements context

Decision Trace

Map UI sections to the decisions and requirements that led to them. Show stakeholders the thread from intent to implementation.

e.g., Sidebar panel linking UI to requirement IDs

Stage Indicators

Show what quality stage (POC/MVP/MMP/PROD) applies to each section. Set expectations about polish level.

e.g., Badge showing 'POC' on experimental features

Validation Points

Mark areas where stakeholder feedback is needed. Make it clear what questions the POC is answering.

e.g., Highlighted sections with 'Feedback needed' callouts

Design Supports Validation

In Catalyst, content patterns exist to drive clarity and decisions. Every section should answer a question or enable an action. If it doesn't serve validation, question whether it's needed.

Tone Guidance

  • Plain language: Write clearly. Avoid jargon unless the audience uses it.
  • Direct: Say what you mean. Don't hedge.
  • Outcome-led: Focus on what the reader can do or decide, not features.
  • Honest: Acknowledge limitations. Don't overclaim.

Related

See Layout for page structure, and Component Patterns for UI implementation patterns.