Page identity, content and display
Page settings control the title, supporting content, layout and key controls for an individual page. Start with the person’s next task, then use settings to make that task clear. Do not use styling or extra content to compensate for a page that asks too many unrelated questions.
Give every page a meaningful title
The Page title is the main heading and browser-page title. Write it as a clear question or task, such as What is your email address? or Check your answers. It can use dynamic values where configured, but a title should still make sense when a value is missing.
Use Short name where the full title would be too long in progress or navigation context. Use CYA title when the answer summary needs a more compact or specific label. Keep these names consistent: a person should recognise that a summary section relates to the page they completed.
Choose content placement carefully
| Setting | Position | Best use |
|---|---|---|
| Page top content | Above the page title | A concise warning or service-level notice that must be seen first. |
| Page bottom content | Below Continue | Secondary help, support links or information needed after completing the page. |
| Progress indicator text | Above the title | A short, accurate progress cue. |
| Check your answers header text | Before the answer list | Explaining how to review and change answers. |
| Check your answers footer text | Before submission | A declaration, important confirmation or final warning. |
Use Markdown for ordinary formatting and Liquid only where content truly varies. Test a long value, a missing value and a value with punctuation. Do not place essential instructions only below Continue or only in a decorative banner.
Use layout settings to support the content
Page width can inherit the service default or use a narrower or wider content area. A normal question page should usually retain the readable default. Consider a wider layout for a map, data grid or a carefully designed table; check it at 200% zoom and on a narrow screen.
The page title margin and title-class overrides are advanced presentation controls. Use them only when they solve a documented design issue and test headings, focus, errors and responsive layout afterwards. Do not use a heading style merely to reduce visual weight; headings must still reflect the information hierarchy.
flowchart TD
A["Define the page's one clear task"] --> B["Write a descriptive H1"]
B --> C{"Is extra information essential before answering?"}
C -->|"Yes"| D["Use concise top content"]
C -->|"No"| E["Keep the page focused"]
D --> F["Choose a readable width"]
E --> F
F --> G["Test in User view at different sizes"]Configure control visibility deliberately
The Continue button visibility setting is appropriate for an information-only or exit page where continuing would be misleading. Do not hide Continue on a page that still expects an answer or action. In a task-list service, the Return to overview link visibility controls the link back to the task list; keep it visible unless another clearly labelled route supports the person better.
Design Check your answers content
The answer page can group answers under page headings or show a flat list. Grouping is usually easier to scan when the journey contains several topics. A flat layout can suit a short, focused summary. For a service with multiple answer summaries, use Block title in All Answers page to make each section recognisable.
Test the actual review page, not just the editor. Check change links, conditional answers, long values, files, summary labels, footer declaration and the submission route.
Task-list and homepage copy
For a Task List page, separate introductory content for incomplete and complete states. The completed state should replace—not contradict—the incomplete guidance. Keep start and resume button labels on a homepage explicit, for example Start a new application and Continue your saved application, so people do not accidentally create a second journey.
Page view actions
Page view actions run before the page is rendered and can delay it. Use them only when the page genuinely needs the result before it is displayed. Put non-blocking work in a later trigger where appropriate, and test a slow or failed dependency so that a person has a recoverable outcome.