Last Update: Jan 22, 2024
Platform: (Web)
Documented by: Nikola Wenger
Intro
Why does form design matter?
Forms in SuccessFactors
A form is used to present data to the user and to allow users to enter data in a structured way. To look up data in forms or to fill out forms are a burden for any user and for some processes it’s a mandatory burden. Layout of forms, fields and proper message handling are essential to increase efficiency, ease of use, completion rate, reduce prone to errors.
Forms are means to an end. They are a necessary evil. Therefore, it is essential to craft forms in a way that users can complete the task with ease and efficiency. The longer the form the higher the frustration and lower the success rate due to length and complexity.
To design a form, follow the standard Fiori Guidelines. This guideline limits the options given in the Fiori Guideline to achieve more consistent forms across SuccessFactors.
SuccessFactors specific restrictions:
Horizontal vs. Vertical Label Layout
In SF we only use the Vertical Label Layout.
- This allows the easy usage of a multi column form layout.
- It makes sure that the labels are never truncated.
Width of Form Fields
The width of Form Fields should be defined by the content that is expected to be inside. Therefore we either have a fixed or a flexible size.
Fixed Width
Flexible Width
Those fields which have a fixed size cannot be changed in width. You do not need to adjust them. The Figma stencils already have the correct size.
Those fields which have a flexible size should be adjusted by the designer. The designer can choose between three sizes: S, M, Fill. The selection should be made based on the expected input length.
(144 px / 9 rem)
(288 px / 18 rem)
(Fills the available space in the column)
Fixed Width
Flexible Width
Finalizing Form Button State
Finalizing buttons at the end of forms should always be enabled even though some required fields are not filled yet. Clicking the button triggers a field validation which informs the user about missing required fields or other errors.
Advantages of keeping the button enabled:
- Users can click the finalizing action at any time. They do not need to find out on their own how to enable the button. For forms with lots of fields this can be time saving.
- Clicking the button triggers the field validation which informs the user in case they missed a field.
- Showing a field validation instead of a disabled button is a more guided experience.
Object Page vs. Wizard vs. Dialog
In the following guideline part you get information on when to use which container for your form design. Below you find a quick overview. Use the yellow buttons to navigate to the respective part inside this guideline to read more about one of the container options.
☑️ Use if
- you have more than 8 fields
- you need fields that open a select dialog or value help dialog or it is likely that this is needed in future enhancements
- your user will use the form on a regular basis e.g. once a month
- your user is an admin
☑️ Use if
- you have more than 8 fields
- you need fields that open a select dialog or value help dialog or it is likely that this is needed in future enhancements
- your user will use the form very infrequently e.g. once a year
☑️ Use if
- you have 8 fields or less
- you don’t need fields that open a select dialog or value help dialog and it is not likely that this is needed in future enhancements
Object Page
Use if
- you have more than 8 fields
- you need fields that open a select dialog or value help dialog or it is likely that this is needed in future enhancements
- your user will use the form on a regular basis e.g. once a month
- your user is an admin
Don't use if
- you have less than 8 fields. Use a dialog instead.
- your user will use the form very infrequently e.g. once a year. Use a wizard instead.
Layout
When designing forms in an object page there are different layout options, which are described with example screenshots in the following.
- One Form is the only element on a page
- One Form is one of several elements on a page
- Multiple Forms in one page
Responsiveness
Fiori offers two options to implement a form: Column Layout or Responsive Grid Layout. In SF we limit this to only use the Column Layout, as this fits better with the vertical label layout.
The ColumnLayout control renders a form group in a column-based responsive way. You as a designer need to decide how many columns your from should have for the different screen sizes.
The number of columns for a langer screen size must not be smaller than the number of columns for the next smaller screen size. E.g. if you allow 3 columns in size L, there must be 3 or more columns in size XL.
Possible options for each screen size:
XL – max. 6 columns
L – max. 3 columns
M – max. 2 columns
S – 1 column
Use 3-4 columns dependent on the number of fields inside the groups.
If you have only 1 group use a dialog instead.
Use 3-6 columns dependent on the number of fields inside the groups.
If you have more than 6 groups consider dividing the form into multiple forms.
Allocate more columns for bigger groups
For an unbalanced number of fields between groups allocate more columns for the bigger group using the property "columnLayout".
Avoid columns with only one field
The UI5 default allocates 2 columns for 2 groups. To achieve a balanced layout developers need to overwrite the default using the property "columnLayout".
Limit the field width to max. 500px / 31,25rem
To achieve this developers need to set a max-width for the form container. Make sure that the white background still stretches to align with content above or below the form.
Don't allow endless stretch of fields
To improve the readability of a field it is recommended to limit the width of one field to a maximum of 500px / 31,25rem.
Wizard
Use if
- you have more than 8 fields
- you need fields that open a select dialog or value help dialog or it is likely that this is needed in future enhancements
- your user will use the form very infrequently e.g. once a year
Don't use if
- you have less than 8 fields. Use a dialog instead.
- your user will use the form on a regular basis e.g. once a month. Use an object page instead.
Grouping
Don't create complex forms within one wizard step
Don't create complex forms within one wizard step
Column Layout
Limit the number of columns
- Limit the number of columns to 1-3 for screen size XL dependent on the number of fields. This improves efficiency because there is a clear reading order for the user.
- Limit the field width to max 500px / 31,25rem to avoid endless stretch.
Don't use more than 3 columns in one wizard step
- One wizard step should have 8-10 fields
- If you use more than 3 columns this will result in only 1-2 fields per columns which will affect readability and mess up the reading order.
Dialog
Use if
- you have 8 fields or less
- you don’t need fields that open a select dialog or value help dialog and it is not likely that this is needed in future enhancements
Don't use if
- you have a complex form with more than 8 fields. Use an object page or wizard instead.
Fixed dialog width of 32 rem
To increase consistency between form dialogs it is recommended to use a dialog width of 512px / 32rem. This results in a field width of 480px.
To improve readability of text it is recommended to have between 8 and 12 words within one line dependent on the language. The reason is that with more words in one line it is difficult for the eyes to find the next line without irritation. In our case this is especially relevant for text area fields.
Single column layout
Use single column layout
For simple forms it is recommended to use a single column layout. Your users will be faster in completion because they don't waste time understanding the form and reading order.
Don't use multi column layout
Using multi column layout in this case would increase uncertainty about the reading order. Would you read from left to right or in a newspaper-like order?
Complex Forms
Progressive Disclosure
Under construction
In general, forms with up to about 20 editable fields or less have the best usability. Avoid larger forms.
Draft Handling
Draft Handling - Save as draft
“Save as draft” as specified by Fiori Guideline is essential and is applicable for create and edit use cases.
Rational:
“Save as draft” supports to increase efficiency and completion rate and reduces frustration.
This is especially true:
If users collect data that they usually don’t have at hand such as IDs that they need to look up. Users must not collect data somewhere before filling out the form. Users don’t want to come back and fill out the form again.
If users started to fill out a form with longer text field.
Special Fields
Combined Fields
It is possible to combine multiple fields into one label-value-pair. The pair of values should provide an easy recognition of the information pair (Street and Number)
It is recommended that both fields are stated in the visible label describing the expected input. You can concatenate them using "and" (Street and Number).
Invisible labels for each individual field are mandatory for the screen reader to announce the purpose of the focused field (Street + Input, Number + Input).
Sometimes users have multiple options in which format they want to provide an input. In this case you can combine a select input with the actual value field. The select input is to choose the input format of the value field. The value field type can change based on the selected input format.
: Active Period can be as of a date with open end or for a period with defined start and end date. The field type changes based on the selected input format:
Date Range -> Date Range Selection
As of Date -> Date Picker
Use a select input to choose the input format
- Make sure that the label describes clearly what input is expected in both fields. Invisible labels are mandatory for both fields.
- For screen readers annotate "Role: Group" around the combined fields so that they are announced as a group.
Avoid combining other fields with radio button options
Combining other form fields with radio buttons
- makes the UI cluttered and difficult to understand
- can cause a11y issues
Duration Field
Single Attachment
Indicating Old Value
Some UIs in SuccessFactors require that the user sees an indication of the old value once they edited a field. Old value is always the value that was last stored to the database. Only use this for editing scenarios of effective dated objects.
Combo Box with two column layout
Use the combo box with two-column layout if:
- You need to display additional information for the selection options, such as currencies, country abbreviations, or system abbreviations.
- Users can filter both columns simultaneously showing only matching entries.
Message Handling
Leverage Fiori's message handling concept to support users completing a form successfully.
Accessibility
Figma