How to design a mobile app form

Decide what the form is really for

A form exists to collect a specific set of things, and the first job is to write that set down. A sign up collects a name, an email address and a password. A short form that collects exactly what it needs is finished in three fields, and one that collects a little more is a form people abandon.

Every field has a cost. It takes vertical space, it adds a step, and it is another chance to get something wrong. If a field is only sometimes needed, that is a question about when, not a field to add and hope it is rarely filled in wrongly.

If the form has more than about six fields on a phone, the job is probably two forms. Split it at the point where the data changes hands, such as the step that creates an account and the step that configures the thing the account was made for.

• Write the list of things the form collects before designing it
• Every field costs vertical space and a chance to get it wrong
• More than about six fields on a phone means two forms

Note: The form is not the flow. If the thing being collected is needed at two different moments in the product, two shorter forms usually work better than one long one with a complicated order.

One field per row and a readable order

One field per row. On a 390-pixel-wide frame a two-column form gives each field about 160 pixels, which is enough for a name and not enough for an email address. Stacking the fields also gives you a reading order that needs no explanation, top to bottom, and that is the order the eye takes anyway.

Order the fields the way they get asked. If the app needs an email address to find your account, the email field comes first even if the name matters more to the user. If one field depends on another, the dependency decides the order. The order should follow the conversation, not the shape of your database.

The Form component in the palette holds the fields as children, so the group moves as one and the rows keep their spacing. The Form field in the insertable library is a ready-made field, so you do not rebuild the label and input pairing on every screen.

• One field per row on a phone
• Order follows the order the information is asked for
• The Form component holds the fields as children
• Form field pairs a label and an input for you

Note: The palette holds 58 component kinds, and a form needs only a handful of them. Choosing the control before you place it is what keeps the row heights and the label sizes consistent from one field to the next.

Labels that match the input

A label has to say what goes in the box and in what form. Place of residence is vague; Postcode is not. Each label should name the thing and imply the shape of the answer, so the user can tell at a glance whether to type a word, a number or a date.

Keep the label above the input. A label to the left of an input pushes the input off the edge on a narrow frame and forces a fixed-width column, which is what makes forms tiring. A label above also reads in the same order as the fields.

Match the control to the answer. A short set of options is a Radio group, a list of independent choices is a Checkbox, a single on or off is a Toggle or a Switch, and a number in a range is a Slider. The Input component is for free text. The login screen guide applies the same rules to a smaller form.

• The label names the thing and implies the shape of the answer
• Labels above inputs, not beside them
• Radio group for a small set of options, Checkbox for independent choices
• Toggle or Switch for one on or off, Input for free text

Show the validation and empty states

A form mockup that only shows the filled-in version is hiding half the design. Show the state where a field has an error and the state where a required field is empty, because those are the states people actually meet. An error needs a message, a place for it to go, and a way to fix it.

Decide when the error appears. On the field, right below the input, so the message is next to the thing that is wrong, or at the top of the form as a summary, which is better when there are several errors to fix. Both are legitimate; an error somewhere unrelated is not.

The empty state of the input is worth drawing too, because the placeholder text is a design decision. A placeholder that says Email address disappears the moment the user types, and a real label above the field is what carries the meaning afterwards.

• An error state with a message and a way to fix it
• The error sits directly under the field it belongs to
• Placeholder text as a hint, never as the only label
• Empty and filled versions of the same form

Note: A mockup cannot show a real validation rule, so write the trigger in a short note beside the frame. What matters for the design is the space the error message takes and where it sits.

The primary action and where it sits

One primary action per screen, at the end of the form, and it should be the only thing that looks pressable. On a phone the action is usually a full-width button below the last field, because the thumb reaches the bottom of the screen and the top of a long form is out of reach. A keyboard that covers the button is why it sometimes sits inside the scrolling area.

Say what the button does. Continue if the form is only part of a flow, Create account if that is what happens, Save if the data is kept. A button labeled Submit tells the user nothing about what they will get, and a button that says Continue but ends the form is worse.

If the form can be canceled, the cancel action belongs beside or below the primary one and looks different. Two identical buttons at the end of a form is how people lose something they meant to keep.

• One primary action, full width, at the end of the form
• The button label says what happens next
• A secondary cancel action that looks different

Review the form on a 390×844 frame

Review it on the phone, not on the desktop. The default mobile frame in App Builder is 390×844, the iPhone 14 preset, and it is the size the form will be read at. Put the form in that frame, then look at it with the keyboard area in mind: do the last field and the button both fit above the bottom edge?

Check the narrowest frame as well. The iPhone SE preset is 375×667, and a form that works at 390 can still crowd at 375, particularly when a label wraps to two lines. A field whose label wraps pushes everything below it down, and the button can end up off screen.

Then read the form top to bottom as if you were filling it in, and ask at each field whether you know what it wants. Any field where you hesitate has a label that needs work. The design system guide covers keeping field patterns consistent, the mobile app screen guide covers the rest of the screen, and the complete Canvasola guide covers the app itself.

• Reviewed on the 390×844 default mobile frame
• Checked on the iPhone SE 375×667 as well
• The last field and the button both fit above the bottom edge
• Read top to bottom without hesitation at any field

Note: The product tour, and where the App Builder sits inside it, is covered in the product guide.

A checklist you can reuse

• The list of things the form collects is written down, and every field is needed
• One field per row, in the order the information is asked for
• Each label names the thing and implies the shape of the answer
• The control matches the answer: Radio, Checkbox, Toggle, Switch, Slider or Input
• An error state and an empty state both exist as frames
• There is one primary action, with a label that says what happens next
• The form has been reviewed on 390×844 and on 375×667

Common mistakes to avoid

• Putting fields side by side. Two columns on a 390-pixel frame leave about 160 pixels per field, which an email address will not fit into. One field per row and the reading order comes free.
• Ordering the fields by the database. The order should follow the order the information is asked for, with dependent fields after what they depend on. A sensible data model rarely is the sensible screen order.
• Using a placeholder as the label. A placeholder disappears as soon as the user types, and the field then has no name. Put a real label above the input and treat the placeholder as a hint.
• Showing only the filled-in form. Most people meet the error state before they meet the happy path. Design it, and leave room for the message under the field.
• Labeling the action Submit. Submit tells the user nothing about what happens next. Say what the button does, and keep the cancel action somewhere less inviting.

Frequently asked questions

How many fields should a mobile form have?

Fewer than you think. Every field takes vertical space on a phone, adds a step and adds a chance to get something wrong. If you need more than about six, the job is probably two forms, split where the data changes hands.

Should the label sit beside the input or above it?

Above it. A label beside an input needs a fixed-width column, which on a 390-pixel frame squeezes the input and makes a long form tiring to scroll. Labels above the fields also read in the same order as the fields themselves.

Can I use one component for every kind of answer?

No, and the difference matters. The Input component is for free text, a Radio group for a small set of options, a Checkbox for independent choices, a Toggle or a Switch for one on or off, and a Slider for a number in a range. The right control tells the user how much freedom they have.

How do I show an error in a mockup?

Draw the field in its error state, with the message placed directly underneath it and space reserved for that message on every field. A mockup cannot enforce a real validation rule, so write the trigger in a note next to the frame for whoever builds it.

This guide is part of the app builder guides collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.