Skip to main content

Form Guidelines

These guidelines help you design form-type interfaces for the SAP Engagement Cloud platform with good usability and a coherent style.

What Are "Forms" in SAP Engagement Cloud?​

An interface is called a "form" when the focus is on users inputting values, mostly through various input fields — text inputs, select drop-downs, checkboxes, radio buttons, etc.

Due to the nature of web interfaces, many screens and dialogs in SAP Engagement Cloud can be considered forms, even if they don't feel like a traditional full-page form (e.g. the "Email Basics" panel in VCE).

The design of these forms should guide the user to fill in the form correctly, reduce time and mental effort, help the user recover from errors, and support accessibility.

Components​

  • Each component comes with its own design guidelines and states — check the component guidelines before using them in forms.
  • Pick the right input for the right data. Read the component guidelines and look at examples inside and outside SAP Engagement Cloud.
  • Only ask users what you absolutely need. If you already know something, pre-fill the input.
  • The size of the input should reflect its content — use a narrower text input for a single word like "First name", a wider one for "Title", and a multi-line text box for "Description".
  • Avoid splitting inputs into sub-inputs (e.g. phone number should be a single input field).
  • Always label inputs.

Layout and Structure​

  • Use a single-column layout to keep the flow linear. A narrow, fixed-width container helps. Multiple inputs in a single row are fine when it makes sense (e.g. First name and Last name), but shouldn't break the linearity.
  • Group inputs into sections and order inputs naturally — group related inputs by topic (e.g. "Profile info", "Regional details") or as sub-steps.
  • Use steps to break forms into logical steps (e.g. "Campaign settings" and "Scheduling" as separate pages).
  • Use conditional logic to display further inputs based on the user's previous actions — only adjust what's ahead of the user in the flow.
  • The first input in the form should be auto-focused.
  • Forms should be easily navigated with a keyboard using the Tab key.
  • Avoid having multiple submittable forms on the same page.
  • Avoid dialogs and JavaScript popups that can break the linearity of the form (modal dialogs are acceptable).

Guidance​

  • Make sure the purpose of the form is explained on the interface — this can be implicit through the title and available inputs.
  • For multi-step workflows, show the user where they are with the Steps Bar component.
  • Use placeholder values as secondary labels. For text inputs, use a realistic example (e.g. for "Phone number": "e.g. +36 1 1234 567"). For selects, use a call to action (e.g. for "Category": "Select category").
  • Mark required fields or optional fields depending on context. For mostly-optional forms, mark required fields with an asterisk or "(required)". For mostly-required forms, mark optional fields with "(optional)".
  • "Submit" or "Next Step" buttons should be at the end of the form.
  • Validation-critical helper text should be visible next to the input.
  • Use tooltips to elaborate on input functions.
  • If the interface requires training, add a "Learn More" link to the documentation.

Writing​

  • Use copywriting guidelines and stick to the SAP Engagement Cloud vocabulary.
  • Avoid negative sentences (e.g. use "Enable AI" instead of "Disable AI").
  • Certain layouts only make sense in certain locales — use layouts that work for most localizations.
  • Buttons should explicitly state their actions (e.g. "Next Step" instead of "Submit").

Errors​

Preventing Errors​

  • Communicate expected values using helper text or tooltips, and limit what users can input (e.g. drop-down instead of a free text field).
  • Be forgiving when accepting input formats (dates, phone numbers, etc.).
  • If possible, disable the "Submit" button until all required fields are valid, and use a tooltip to explain what needs to be done.
  • Ask for confirmation on certain form actions to prevent accidental submissions.

Validating Inputs​

  • If possible, validate input as soon as the user is done working with it ("on blur" event).
  • Avoid validating the input until the user has finished entering a value, unless live validation makes sense (e.g. password strength checker).

Error Feedback​

  • Display error feedback inline to retain context (e.g. below the input).
  • The error message should explain what is wrong and, if possible, propose a fix.
  • An indication that there was a form submission error should be in view when validation is done (e.g. a sticky generic error at the top of the page), alongside inline error messages.
  • The tone of the error message should be respectful and helpful.

Recovering from Errors​

  • The user should not lose their work. Retain as much input as possible, even inputs with errors.
  • Provide undo and redo support.
  • Provide an "escape route" to a safe state (e.g. a "Cancel" button that rolls back to a previous state).

Accessibility​

  • Arrange inputs to support keyboard navigation (Tab key).
  • Avoid depending purely on color — use text or iconography as well.
  • Avoid JavaScript popups — they hurt linearity and are bad for accessibility.