Workflows are one or more set of tasks, usually as forms, that have to be completed to create an intended result or effect.
A form is any interface that collects information from one party, so that a product or service can be provided. In software terms, it is the interface that collects data to be processed (input) and returns it as something else (output).
Form sections are groupings of conceptually similar fields, and may or may not have a title and subtitle.
Blocks and Modals are the structures that hold form fields and provide calls to actions like submit and cancel.
Multi-step forms are long forms divided into different steps that are displayed one at a time (different than sections, which are displayed at once), very often accompanied by Trackers.
A field is a question being asked in a form. See field structure for more information.

Key Aspects of Forms

The three key aspects to every form are:

Words - Forms are interfaces based on questions and answers between parties that can only interact through the usage of such interfaces. Therefore the most important aspect of a form is how clear the questions are and how easy it is for users to understand the format in which the answer is expected of them.
Layout - A visually ordered display of answers and questions will ensure that forms can be filled quickly, easily and accurately, while still delivering a pleasurable user experience.
Flow - Create logical order and interactions that increase accuracy, speed and improves the experience of filling a form. By adding interactive behaviors and timely feedback to the users, the form becomes dynamic and guide the user through the workflow.

Form Structure

Forms are made by one or more fields inside blocks or modals. Fields can be grouped into form sections. Forms at Carta are made to stress the vertical structure and guide the user' eyes between question and answer, allowing the user to focus on one thing at a time

Fields are stacked on top of each other instead of side by side.
Field labels must be on the left side in most cases.
Field help, errors and additional info stay below the input field.
The submit button (or other buttons) are on the wrapper block
Clarity is more important than brevity, so it is fine to have longer forms provided they are clear and easy to navigate

Form structure

Field Structure

A Form is composed by a series of questions. In ink, we name each of those questions as Fields. These elements are composed by a series of smaller structures, such as: field label, field control, field errors, field help and field info.

Field label

Questions we want users to answer in any form field. The quality of our questions will determine the quality of the data we collect.

Field control

Reserved area for controls, elements where users will answer the questions. All data entry elements, including: input, select, checkbox, radio button, text area, file picker, date picker.

Field error

Reserved area for errors that may occur when the form is submitted. Every error that is related to the specific field should be written in a field error element.

Field help

Reserved area for texts that can help the user fill out the field as expected. It can include formatting tips, examples of possible entries or explanations on how to come up with a value for that field.

Field info

Reserved area for texts that provide information on how that field can interact with other parts of the application.

Selecting Appropriate Controls

The type of control in a field has a very large impact on a form's usability.

Control types should be determined by the type of information being collected in a particular field. In general, we want to minimize the number of different choices a user has to deal, while never preventing the entry of correct information. This can be a non-trivial decision to make.

The following information types should be collected using specific, predictable control types:

Controls for short text and numbers

For names, ID numbers, phone numbers, e-mail addresses, passwords, document names, quantity, price, dates, etc.

Use a single-line text control.
Always use appropriate mask and validation, preferably with auto-completion.
Related components: NewTypeahead, NewInput, NewDatePicker

Controls for long text

For company name, person or user names, placenames, ID numbers, phone numbers, e-mail addresses, passwords, document names, quantity, price, dates, etc.

Use a multi-line text control.
Always use appropriate size and validation.
Related components: NewTextArea

Controls for selecting one among two to five items

Use radio buttons.
Exception: use a checkbox for collecting consent to an agreement (contract, etc.).
Related components: NewRadio

Controls for single selection among more than five items

Use a select control.
Related components: NewSelect

Use checkboxes.
Radio buttons should generally be used for yes/no questions. However, do not mix multiple control types in the same field.
Related components: NewCheckbox, Agreement

Controls for files, non-text data or data exported from another service/application

Use a file upload control.
Related components: FilePicker

Drop or choose a file

Handling data formats in inputs,

Automatically formatting data, or masking, in inputs is useful when consistency is key. It is helpful for users to see what format their inputs should be in beforehand, rather than throwing an error when they don’t enter it the right way. Use masks when:

An input is always formatted in a certain way. This includes:

Phone numbers
Money
Dates
Zip codes
Addresses
SSNs

You only want letters or you only want numbers.
You want a specific number of decimal places.
You have a minimum or a maximum value.

Note: even though masks are enormously helpful for users, it is still good practice to also have help text providing an example of the correct format for the data.

The following are examples of masks and how they are used inside Carta.

Phone numbers

The ink input with phone mask now only accepts numbers, so users don’t have to — and can’t — type dashes or parentheses:

Decimals

If a user types .3 into a field with a money or decimal mask, it should be converted to 0.3 automatically. This happens before the form is submitted, providing the user a chance to see the change.

Integers

Since numeric inputs only accept numbers now, we don’t have to worry about commas. It will only take numbers, and we add commas in behalf of the user. And if you set a maxValue, the input won’t take numbers that go above that value. On the example below, I’m trying to press 9, but the input takes only 999 as a maximum.

Dates

We are also applying a mask to date input fields. That means you can now only type in numbers, and characters like slashes or dashes are ignored:

Money

We are introducing a new way to control how users can type in currency amounts. Like in the previous examples, ink input using a mask will only accept numbers, and will handle formatting automatically. That means we will add the thousand separator, will allow values starting with a period for decimal values, and will enforce a fixed decimal scale, when desired. We also support custom masks for more specific needs.

Masking makes interactions predictable, with the goal of reducing error rate and improving data quality. It does this while making it easier for engineers to build, and for Carta to provide a great customer experience.

No Input Placeholders

Carta does not use placeholder text inside fields as a general rule. Even though it is a common practice, placeholders are not really helpful and actually worsen the user experience: We don't allow that because placeholders inside inputs:

Either just repeat the label or try to provide help that disappear when users start typing
Trick users into perceiving that the question is already answered
Disappear before users see the text, especially if they watch the keyboard when typing
Are forcibly short

In short, use the field help element instead of placeholder text. The only thing that should go inside form inputs are the user answers. Also, empty input fields are an effective indication that that answer is missing and naturally pulls the users' attention.

Add help text below the answer field. It is always visible and allows for longer helper text

Don't

Placeholders inside inputs make them look filled, and the help disappears when users type. It is also impossible to provide longer texts

Add help text below the answer field. It is always visible and allows for longer helper text

Don't

Placeholders inside inputs make them look filled, and the help disappears when users type. It is also impossible to provide longer texts

The only accepted exception are placeholders inside table cells, as there is no available space for properly displaying helper text around the cell.

Autocomplete

Autocomplete is an attribute supported by HTML forms and inputs which allows them to be filled out faster by using information the user has saved in the browser.

There are two kinds of autocomplete: form autocomplete and input autocomplete. Though they work similarly (by being able to be set to "on" or "off"), each one has its own particularities.

Learn more about autocomplete autofill behavior

Form autocomplete

The form autocomplete turns all the inputs in the form to the same setting. Unless all the inputs need autocomplete, a good practice would be to set the form autocomplete to off and then set individual inputs to on as needed.

Input autocomplete

The input autocomplete works by setting a correct name for the input and adding one of 53 valid values available for the autocomplete attribute. Having the correct structure for the autocomplete not only helps the user complete the form faster, but also improves accessibility in your page. The input autocomplete also accepts an off value, but we explain ahead why sometimes it doesn't work.

<Field isStacked htmlFor="autocomplete-input-1" label="Email address">
  <NewInput id="autocomplete-input-1" autocomplete="email" name="email" />
</Field>

Email address

<Field isStacked htmlFor="autocomplete-input-2" label="Email address">
  <NewInput id="autocomplete-input-2" autocomplete="autocomplete-invalid" />
</Field>

Email address

Set a valid autocomplete value in conjunction with a name

Don't

Just set the autocomplete to a non-valid value

<Field isStacked htmlFor="autocomplete-input-1" label="Email address">
  <NewInput id="autocomplete-input-1" autocomplete="email" name="email" />
</Field>

Email address

Set a valid autocomplete value in conjunction with a name

<Field isStacked htmlFor="autocomplete-input-2" label="Email address">
  <NewInput id="autocomplete-input-2" autocomplete="autocomplete-invalid" />
</Field>

Email address

Don't

Just set the autocomplete to a non-valid value

Chrome Problem

Chrome browsers are known for ignoring the autocomplete attribute when it's off, so the best way to make it off is to assign a non-valid but semantic value to the autocomplete:

<Field isStacked htmlFor="chrome-autocomplete-off" label="Email address">
  <NewInput id="chrome-autocomplete-off" autocomplete="personal e-mail" />
</Field>

Why Chrome ignores autocomplete="off"

Address forms

Moving forward, all address forms should utilize the AddressAutocomplete component from the @carta/identity team. See this guide for more information.

Form Validation

General guidelines

Validate only on submit.
Validate on each step.
Don't disable the submit button.
A form must have enough structure and information to tell you how to fill out the form.
Error messages should tell the user how to solve the problem—not just what's wrong.

In short, a form should have clear error messages that indicate how to fix the problem, and validate at times that make it easy for the user edit their mistakes.

Validate on submit

Don't throw error messages while the user has only partially completed the form or a field. When an error message pops in and out of the form as a field validates live it's visually jarring, it confuses the user with more information than they need, and we're accusing the user of doing something wrong before they've finished entering the values. They probably already know it's wrong.

Validate on each step

For multiple page interfaces validate on each step. Don't throw errors that redirect a user to a different view or a previous page. This is especially aggravating when the form doesn't save between pages (another pattern we discuss), forcing the user to re-enter information.

Don't disable the submit button

Don't disable the button, the submit button is a tool to test the form. Think of clicking submit as the user asking the form "I believe my form is complete, do you think it's ready?". This is the time to throw an error.

An aside on disabling the button: The user doesn't know why the button is disabled. When the button can't be clicked to yield an error the user is blocked from being able to figure out how to move forward. A user may not be able to identify a button as disabled. They could be new here and think our buttons are pale blue. They won't know why the website doesn't work when they click on it.

A form must have enough structure and information to tell you how to fill out the form

Rely on helpful formatting, placeholders, tools such as cleave, input types, and helper text. A user must always have enough information from the form to be able to enter a correct value before clicking submit. Be careful if you're correcting or constraining a value. Make sure the user knows that the values have been changed. Trust our users to know the task they want to accomplish—our job as designers is to help a user structure the data.