Short answer: A settings screen people can follow is sorted by frequency and risk: the settings that change often sit at the top, the rare ones at the bottom, destructive actions get their own section, and every row uses the same list item pattern. Build it with List item, Toggle, Switch, Radio group and Slider.

Sort settings by how often they change

Most settings screens fail because they are a list of everything the product can configure, in the order the code happens to store it. The person opening the screen has a different order in their head: the one thing they came to change, first.

Sort the list by frequency instead. The settings people change weekly, such as notifications, theme and language, go at the top. The ones they change occasionally, such as account details, privacy and linked accounts, go in the middle. The ones they change once a year, such as advanced keys and data export, go at the bottom, or behind their own screen where they do not clutter the everyday list.

A frequency sort also tells you how many screens you need. If the everyday settings fit on one screen, they belong on one screen. If the rare ones would push them off the bottom, give them a second screen and say so on the first with a clear link.

  • Weekly settings at the top, where they are easy to reach
  • Occasional settings in the middle
  • Rare settings at the bottom or on their own screen
  • One screen for the everyday list, one for the rest

Note: Ask three people which setting they came to change. The answers are usually the same two or three, and that is your top of the screen.

Separate preferences from destructive actions

A preference changes how the app behaves. A destructive action removes something. Putting them in the same list means a person looking for a switch can put a finger on the wrong row, and the cost of the mistake is not the same for both.

Give the destructive actions their own section, separated by a Divider and usually placed at the very bottom of the screen, after a gap that tells the eye something has changed. Sign out is mild. Delete account and reset all data are not, and they do not belong next to a toggle for sound effects.

Ask for confirmation in a Dialog or a Bottom sheet, and name what is being deleted in the confirmation itself, not just the action. Delete account is clearer than Continue, because it repeats the object of the verb where the person is deciding. The mockup tutorial covers the same care applied across a screen set.

  • Destructive actions in their own section at the bottom
  • A Divider and a clear gap before the section
  • Confirmation in a Dialog or a Bottom sheet
  • The confirmation names what is being deleted

Note: Sign out is recoverable and delete account is not. Treating them as the same kind of row is the mistake this section is about.

Match the control to the setting

The control tells the reader what kind of change they are making, so pick the one that matches the shape of the setting. A Toggle or a Switch for something that is on or off, a Radio group for a choice among a few named options, a Slider for a value in a range, a Stepper for a number with small steps, a Checkbox for a single opt-in, and an Input when the value is typed.

The distinction that catches people out is between a Toggle and a Radio group. If the reader can pick one of three notification levels, that is a Radio group, because the options are a set of choices. A pair of on and off switches is a set of separate facts, and each one gets its own row.

The label does half the work. Notifications is too vague, because it does not say what happens when it is on. Push notifications, Email summaries and Allow sounds are labels a reader can act on, and the same rule applies to the value on the right of the row.

  • Toggle or Switch for an on or off setting
  • Radio group for a choice among named options
  • Slider for a value in a range, Stepper for a small count
  • Checkbox for one opt-in, Input for a typed value

Note: A control that shows more than one setting at a time is a display, not a control. If a row shows three numbers, it should be three rows.

Build every row from the same list item pattern

Every row on a settings screen should be the same shape: a label on the left, a control or a value on the right, and the same height from top to bottom. When every row matches, the reader reads the left column as a list of names and the right column as a list of values, and the screen becomes scannable.

The List item component in the palette is built for that, and the List row from the reusable component library is the version that arrives already assembled. Two of the other six insertable components belong on this screen too: the Nav header for the title and back control, and the Tab footer if the settings live inside a tabbed shell.

Build the first row, copy it, and change the label. Copying keeps the height, alignment and spacing, which is more reliable than rebuilding each one. Use Ctrl/Cmd+D to duplicate, and the 8 pixel placement grid to keep the right-hand controls in a straight line down the screen.

  • Label on the left, control or value on the right
  • One row height for the whole screen
  • Copy the first row instead of rebuilding each one
  • List item for the row, Nav header for the title

Note: Canvasola gives you seven insertable reusable components, and you cannot define your own. Plan the screen around the seven, and use auto-layout for the group that holds the rows.

Add a search field only when the list is long

Search in a settings list is a sign that the list is too long, not a way to fix one. If a person has to type to find a setting, the list has failed to be sorted, and no amount of searching makes it good.

The threshold worth using is around twenty rows. Below that, the list is scannable and a search field adds an empty box at the top the reader has to look past. Above that, add the Search component and let people type a few letters, or split the screen by group with a short index of sections.

A middle option is grouping. Sections with headings, separated by Divider components, let a reader jump to the group they want without a search box, and they cost nothing in effort because you have already sorted the settings by frequency.

  • Under about twenty rows, no search field
  • Over that, add the Search component
  • Grouped sections with headings as the cheaper fix
  • Divider between groups, generous space above each heading

Note: Search that returns nothing is a worse experience than no search. If the setting list is short, the search field is the first thing to cut.

Review the screen for accidental taps

Most settings accidents are spacing accidents. A row of toggles packed tightly above a delete button means a thumb can hit the wrong target, and the confirmation is doing work the layout should have done.

Check three things. The destructive section is far enough from the everyday rows that a tap cannot reach both. The confirmation is a real interruption, with the object of the action named in it. And no control sits at the very bottom of the screen where the thumb rests, because that is where a stray touch lands.

Then read the screen as a whole rather than row by row. The order should look like a list of things a person cares about, with the risky things at the end and clearly separated. The mobile screen guide covers the spacing and grid rules that keep that order visible.

  • Destructive rows are separated by a real gap
  • The confirmation names the object of the action
  • No control at the very bottom edge of the frame
  • Row order reads as priority, not as a database dump

Note: Zoom out and look at the whole screen at once. If the bottom of the screen looks like a cliff of buttons, the spacing is not doing its job yet.

A checklist you can reuse

  • Settings are sorted by how often they change
  • Destructive actions have their own section at the bottom
  • Each setting has a control that matches its shape
  • Every row uses the same list item pattern
  • Rows share one height, with the 8 pixel grid holding the edges
  • A search field appears only on a long list
  • The screen was reviewed for accidental taps

Common mistakes to avoid

  • A list in storage order. Settings screens often follow the order the code keeps them in. Sort by how often the setting changes instead.
  • Delete next to a toggle. A destructive action sitting under a row of switches is one stray thumb away from a mistake. Separate them.
  • The wrong control. Three notification levels are a Radio group, not three switches. The control tells the reader what kind of choice they are making.
  • A row per screen. Rebuilding every row by hand produces different heights and drifting edges. Copy one row and change the label.
  • Search as a fix. Adding a search box to a long list hides the fact that the list is not sorted. Split it into sections first.

Frequently asked questions

How long should a settings list be?

Long enough for everything the product can configure, but the screen the person sees should stay short. Keep the everyday settings on one screen and move the rare ones to a second one. A list of around twenty rows is the point where scrolling starts to annoy, and a search field becomes worth adding.

Should I use a Toggle or a Switch?

They do the same job in Canvasola, so pick one and use it on every screen, because the real cost of mixing them is that the reader has to work out whether the control means something different. The <a href="/blog/design-a-mobile-app-screen">mobile screen guide</a> covers the spacing and grid rules that keep a settings list steady.

How do I make a row look like every other row?

Build one row with the List item component, then copy it with Ctrl/Cmd+D and change the label. Copying keeps the height, the label position and the spacing, and the 8 pixel placement grid keeps the controls on the right in a straight line down the screen. The List row from the reusable component library is the assembled version of the same thing.

Can I put a confirmation dialog in the mockup?

You can place the Dialog and Bottom sheet components on a separate frame to show what the confirmation looks like, which is usually how a reviewer wants to see it. The prototype link in App Builder is set on the frame rather than on the button, so a walkthrough can show the settings screen and then the confirmation, but it cannot open a dialog by itself.

Build a settings screen people can follow.

Open App Builder, add a mobile frame, and lay out one list row properly before you copy it into twenty. The reusable List row component keeps every row the same shape.

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.