Service content, branding and languages
These service settings tailor the presentation of one service without changing the library-wide defaults. Use them to add service-specific guidance, header and footer content, layout options and translated content. Keep the experience focused: branding and extra navigation should help people complete the task, not compete with it.
Add service-specific content with purpose
The service can display a Phase banner, Phase banner text and Footer text. Use a phase banner when it communicates a real status or limitation that people need to know. The text supports formatted, dynamic content where configured; keep it short and link to further information only when it is genuinely useful.
Footer content is a good place for contact information or service-specific help. Use descriptive links and avoid repeating the same information on every page if a clearer dedicated help page is available. Any dynamic content should have a useful fallback for missing values.
Keep page width readable
The Screen width and Default page width settings control the available content area. Most question-and-answer pages work best with a restrained reading width. Use a wider layout only when the task needs it, such as an extensive data table, a map or a multi-column review. The Check your answers page can have its own width setting.
flowchart TD
A["What does the person need to do?"] --> B{"Simple reading or one answer?"}
B -->|"Yes"| C["Use the normal readable width"]
B -->|"No"| D{"Does the task need a wider layout?"}
D -->|"Yes"| E["Use a wider service or page setting"]
D -->|"No"| C
C --> F["Test at 200% zoom and on a narrow screen"]
E --> FDo not use a wider page simply to fit more content. Split the task or improve the content hierarchy first. Test tables, sidebars, error messages and long field labels at different viewport widths.
Use sidebars sparingly
The service can display custom left or right sidebar content and an optional automatic page list. Each sidebar can be configured in Markdown or HTML and can be shown or hidden on mobile.
Use a sidebar for secondary, stable information that helps throughout a journey, such as contact details, a short progress explanation or a supporting reference. Do not put essential instructions or validation feedback only in a sidebar. It may be hidden on small screens or missed by someone using a keyboard or screen reader.
If you include the automatic page list, check that its labels are meaningful and that it does not encourage people to skip required steps. Test the complete reading and keyboard order with sidebars visible and hidden.
Maintain header and footer links
Additional header-link labels and URLs are paired values: each label needs a corresponding destination in the same order. Check every link after any edit. Use short, specific labels and avoid adding navigation that takes people away from an incomplete service.
The footer can show selected policy links and either link to a hosted terms or privacy page, or present suitable inline content. Do not publish a generic policy link without confirming it is accurate for the service, its data handling and its audience.
Provide content in more than one language
The Languages setting controls the supported languages for a service, up to 20. Add a language only when the service can provide a complete, reviewed experience in that language. That includes page content, validation messages, choice labels, dynamic content, emails, documents, policies and help routes.
The Builder supports background preparation of translations and context-aware translation generation. Treat generated content as a draft: a qualified reviewer who understands both the service and the language should check meaning, tone, terminology, dates, numbers, links, formatted content, variables and placeholders before release.
| Check | Why it matters |
|---|---|
| Selection labels and stored IDs | Labels can be translated; IDs should remain stable for conditions and actions. |
| Liquid and formatting | Variables, tags, URLs and markup must remain valid. |
| Dynamic and error content | A person must understand validation and next steps in every supported language. |
| Right-to-left or long text | Layout, buttons and tables may need additional review. |
| Support and policy links | They must lead to information in the selected language where promised. |
Protect analytics and personal data
The service can identify selected field IDs for analytics. Treat this as a data-handling decision, not a content feature. Do not tag personal, sensitive or free-text answers without the appropriate legal basis, privacy review and clear understanding of where the data will go. Prefer aggregate service measures over detailed answer tracking.