Form Page Guidelines

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

What Are "Forms" in Emarsys?

We call an interface a “form” when the focus is on users inputting values, mostly through various input fields, such as text inputs, select drop-downs, checkboxes, radio buttons, etc.

Due to the nature of web interfaces, a lot of screens and dialogs can be considered forms in Emarsys, even if they don’t feel like a traditional full-page form. For example, the “Email Basics” panel in VCE can be considered a form.

Since these forms are more like software interfaces, and not necessarily “surveys”, some of the general form best practices that you might use in surveys don’t apply.

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

Components

Each component comes with its own design guidelines, states, etc., these are mostly independent from the form guidelines, so make sure to check out how to work with components before using them in forms.
Pick the right input for the right data. Read the component guidelines, look at examples inside and outside Emarsys.
Try only asking users what you absolutely need. If we already know something, the input can be pre-filled with the data.
The size of the input should reflect its content, e.g. use a narrower text input a single word like “First name”, a wider text input 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.
Make sure to always label inputs.

Layout and Structure

Use a single-column layout to make the flow linear:
- A narrow, fixed-width container helps the linear flow.
- There can be multiple inputs in a single row when it makes sense (e.g. First name and Last name can be next to each other), but it shouldn’t break the linearity of the layout. The user still should be able to read the form “from top to bottom” without confusion.
Group inputs into sections, and order inputs naturally:
- Try grouping related inputs into sections. These sections can be based on topic (e.g. “Profile info”, “regional details”), or can act as a sub-step in the form (e.g. “Select launch type”, “select version to send”).
- Even inside these sections, make sure the order of inputs make sense, e.g. put “First name” and “Last name” next to each other.
Use steps to break forms into logical steps:
- E.g. in our email editor, “Campaign settings” and “Scheduling” have their respective pages.
You can use “conditional logic” to display further inputs based on the user’s previous actions
- E.g. in VCE, selecting the “Recipient source” determines whether you see inputs related to segments, contact lists, etc. Make sure you only adjust what’s ahead of the user in the flow.
The first input in the form should be auto-focused.
The form should be easily navigated with a keyboard, using the tab key to switch between inputs.
Avoid having multiple “submittable” forms on the same page, e.g. don’t have a sign up form and a log in form on the same page.
Avoid using dialogs and javascript popups that can break the linearity of the form. Modal dialogs can work, though.

Guidance

Make sure the purpose of the form is explained on the interface, e.g. “What does scheduling do?”. This can be implicit, the explanation can come from the title, the available inputs, etc.
If it’s a multi-step workflow, make sure to show the user where they are right now, e.g. by using the Steps Bar component. Indicate what’s coming up in the workflow, so the user can see what’s ahead.
Use placeholder values as “secondary labels”. For text inputs, placeholders should be a realistic example to strengthen the purpose of the input, e.g. for “Phone number” the placeholder can be “e.g. +36 1 1234 567”. For inputs with pre-defined options (e.g. selects), the placeholder should be a call to action. e.g. for a “Category” dropdown, the placeholder can be “Select category”.
We can either mark required fields or optional fields, it depends on the context. For a form where most fields are optional, mark the few required fields with an asterisk or a “(required)” label. For a form where most fields are required, mark the few optional fields with an “(optional)” label.
“Submit” or “Next Step” buttons should be located at the end of the form.
- In Emarsys, a common pattern is to put these buttons at the top-right corner of the screen (The Page Title button bar). While this is generally bad practice, as it breaks the flow of the layout, it might make sense to use this variant to stay consistent in a specific product.
Validation-critical helper text should be visible next to the input, e.g. “password must be at least 6 characters long”.
Use tooltips to elaborate on input functions, e.g. for the input “Time zone” you could have a tooltip that says “Time zone is used for automated campaign scheduling”.
If the interface requires training, placing a “Learn More” link to the documentation might help the user.

Writing

Use our copywriting guidelines
Stick to the Emarsys vocabulary, or if that’s not possible, go for the general knowledge.
Avoid using negative sentences, e.g. “Disable AI” switch, where the “on” would mean “AI off”. Instead, use positive sentences, e.g. “Enable AI” switch, where the “on” means “AI on”.
Certain layouts only make sense in certain localizations, e.g. how an American postal address looks vs. how a German postal address looks like. If possible, use a layout that works in most localizations.
Buttons should explicitly state their actions, e.g. “Next Step” instead of “Submit”.

Errors

Preventing errors

Communicate what kind of value the form is expecting, e.g. use helper text or tooltip, and limit what values the user can input, e.g. drop-down instead of an input field.
Inputs should be as forgiving as possible when it comes to accepting formats, e.g. for phone numbers, “+36 30 1234 567”, “06301234567”, and “(30)-1234-567” all should be accepted. It should be up to us to format and make sense of the data.
If possible, communicate the status of the screen with the “Submit” / “Next Step” button. Disable this button until all required fields are filled in and there are no errors, and use a tooltip to tell the user what needs to be done before they can submit the form.
- If this dynamic solution is too much development overhead, the traditional "submit, validate, show feedback" process is also acceptable.
Ask for confirmation on certain form actions to prevent accidental submissions, e.g. when scheduling a campaign.

Validating inputs

If possible, validate input as soon as the user is done working with it, i.e. when the user “clicks out” or “tabs away” from the field (“on blur” event).
Avoid validating the input until the user finished entering the value, unless it makes sense to validate “live” (e.g. password strength checker).

Error feedback

Upon validation, display the error feedback message inline to retain the context, e.g. under the input, as users notice that easily.
The error message should explain what’s wrong with the value, and if possible, propose a way to fix it. This can be implicit, too, e.g. “Password must be at least 6 characters long” = “The entered password is too short. Enter a password must be at least 6 characters long.”
An indication that there was an error with the form submission should be in view when the validation is done, e.g. a “sticky” generic error message at the top of the page (when the page reloads after the submission), accompanying the inline error messages.
The tone of the error message should be respectful and helpful.

Recovering from errors

The user shouldn’t lose work they’ve done. Retain as much input as possible, even inputs with errors, i.e. don’t “reset” the form when an error happened.
Provide the user a way to undo and redo inputs.
Provide an “escape route” to a safe state, e.g. pressing the “Cancel” button rolls back the form to a previous state without errors.

Accessibility

Arrange inputs in a way that it supports keyboard navigation, i.e. switching inputs with the tab key.
Avoid depending purely on color for conveying information. Use different text or iconography.
Avoid Javascript popups altogether. They hurt the linearity, litter the screen with windows, and are also bad for accessibility (e.g. keyboard navigation, screen readers, etc.)