Design guide

A design guide helps a reader plan and design a specific solution with Cloudflare, focusing on the architecture decisions behind that solution before any configuration. A design guide is a focused subset of a reference architecture. The tone is instructional and straightforward.

Write a design guide when a reader needs to plan the architecture of one specific solution, understanding the decisions and trade-offs before they build it. It is not:

• A reference architecture. A reference architecture describes a broad, product-spanning architecture, whereas a design guide narrows to planning one specific solution within it.
• A how-to. A how-to gives the steps to configure a product, whereas a design guide reasons through the architecture decisions and trade-offs before any configuration begins.

For the full comparison, refer to Content types.

• Title: a short verb phrase in the second-person imperative, not a gerund. Prefer "Securely deliver applications with Cloudflare" over "Securely delivering applications".
• Description: name the solution the reader will plan and design, the Cloudflare products involved, and the architecture decisions covered.

Copy this skeleton and adapt it to your solution:

---
title: <Verb phrase naming the solution to plan>
description: Plan and design <solution> with <Cloudflare products>, covering <the architecture decisions>.
pcx_content_type: design-guide
sidebar:
  order: 10
products:
  - product-a
---

Open with two or three paragraphs describing the subject matter and the end state of the solution.

## Intended audience

Summarize who the guide is for and what they will learn.

## <Architecture decision or design area>

Describe the design and the decisions and trade-offs behind it, include a diagram of the architecture, and link out to the how-tos and tutorials that implement it.

## Related links

Point to the reference architecture and product documentation the design draws on.

• Introduction opens with two to three paragraphs describing the subject matter and the end state of the solution the guide details.
• Intended audience summarizes who the guide is for and what they will learn.
• Diagrams show the architecture, which is central to a design guide.
• Notes and warnings flag caveats and trade-offs that affect how the design applies.
• Related links point to the reference architecture and product documentation the design draws on.
• What does not fit: step-by-step configuration procedures. A design guide plans the solution, so link out to the how-tos and tutorials that implement it.

pcx_content_type: design-guide
products:
  - product-a
  - product-b

For more details, refer to pcx_content_type.

• Securely deliver applications with Cloudflare

• Design, not steps. Describe the architecture and the decisions behind it, linking out to the how-tos and tutorials that implement them, because a design guide is a plan an agent reasons from, not a procedure it runs.
• State the end state. Describe the finished solution the guide produces up front, so a reader or agent knows the target before following the design.
• Name the audience and assumptions. State who the guide is for and the infrastructure it assumes, because a design guide is only actionable for a reader with the right context.