This set of notes answers one question:When users need to "feed" information into a system, which control should be used, how should validation work, and how do you avoid driving users away. This is not a component appearance specification, but a decision manual for "choosing controls + designing flows". The audience is product managers, so every term is explained in plain language inline, and every section lands on when to use / how to choose / counterexamples.
One underlying logic runs through the whole piece (from NNGroup usability testing and the 10 usability heuristics (complete table of 10 heuristics · application to complex applications · user pleasure hierarchy · testing methods: 5-user rule/recruiting/remote testing/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample error/competitive evaluation) 10 heuristics):System status must be visible (users need to know whether they clicked successfully and whether their input is correct), users must be able to reverse actions (cancel/undo), recognition is better than recall (provide options instead of making users memorize), prevent errors where possible, and make recovery easy when errors cannot be prevented. All the control guidelines below are concrete applications of these principles in specific scenarios.
The full text is divided into five sections:Overall forms and validation(10 form guidelines + 10 error-reporting rules + date input) → Selection controls(checkboxes / listbox vs dropdown / parameter controls / steppers) → Toggles and buttons(toggle switches / split buttons / cancel vs close) → Copy and login(link label 4S / passwordless accounts) → Multi-step flows and tools(wizards / drag and drop / accelerators / calculator quizzes).
Key numbers to note first:Following basic form usability guidelines raises the first-time error-free submission rate from 42% to 78%(nearly doubled); minimum touch target size 1cm × 1cm; the option-count threshold between listboxes and dropdowns is at 5 options and 15 options; drag-and-drop reordering animation is approximately 100ms; calculators generally accept 2–7 inputs, quizzes accept 5+ inputs;76% of users store passwords on their phones,83% use biometric identification at least occasionally.
1. Overall forms and validation: Let users "fill it in correctly the first time"
Forms are the lifeblood of conversion rates. This section covers three things thoroughly: how to lay out the entire form (10 rules), how to report errors (10 rules), and how to design the most troublesome date fields.
1.1 Top 10 Website Forms Usability Guidelines
Core principle: Form usability is not a new topic, but basic rules are ignored again and again — following them can raise the "first-time error-free submission rate from 42% to 78%". Why: every extra field and every ambiguity is an opportunity for abandonment; cutting fields, cleaning up layout, and clarifying errors can potentially double conversion rates directly.
| # | Guideline | How to do it / Key points | Counterexample |
|---|---|---|---|
| 1 | Keep forms short | Delete non-essential fields; if information can be inferred from elsewhere or collected at a later stage, do not ask for it now | A form cut from 6 fields to 2 fields saw a clear increase in completion rate |
| 2 | Visually group related fields + labels | Place labels close to input boxes; on mobile/short forms place labels above fields, on long desktop forms place them beside fields; group fields by topic and add labels for screen readers | —— |
| 3 | Single-column layout | Multiple columns interrupt the vertical filling flow and force the eye to refocus | Exception: short related fields such as city/state/zip code can be placed on the same line |
| 4 | Order fields logically | Credit cards follow card number → expiration date → security code; delivery options ordered by frequency of use (standard → 2-day → 1-day) | Starbucks iPhone App hides the commonly used "decaf" option on the right side, requiring horizontal scrolling |
| 5 | Avoid placeholder text | Placeholders are gray hint text inside input boxes — they are easy to ignore, disappear as soon as input starts, and users cannot look back at them | —— |
| 6 | Match field type to input box size | Box width implies expected input length; for 2–3 options use radio buttons instead of dropdowns | City field: 99.9% of city names are ≤19 characters, so set the box to that length |
| 7 | Distinguish required vs optional fields | Minimize optional fields as much as possible; clearly mark optional fields, do not make users guess through trial and error | —— |
| 8 | Explain input/format requirements | State password complexity and phone number format clearly on the spot; do not enforce unnecessary restrictions such as mandatory parentheses/spaces | Netgear password reset only displays password requirements after an error, which is frustrating |
| 9 | Avoid reset buttons | The risk of accidentally tapping "Reset/Clear" far outweighs genuine need; sensitive forms can offer "Cancel" but reduce its visual prominence | TSA complaint form's "Clear Form" button violates this, and is placed closer to input boxes than "Preview", making accidental taps extremely likely |
| 10 | Error messages must be clear and visible | Combine multiple cues (red text + bold + field outline);preserve content the user has already entered to make editing easier | —— |
1.2 10 Guidelines for Reporting Errors in Forms
Note: Two articles in this batch cover the same set of 10 guidelines(“10 Design Guidelines for Reporting Errors in Forms” and “How to Report Errors in Forms: 10 Guidelines”), which have been merged and deduplicated here.
Core principle: Good error handling = errors are easy to notice, easy to locate, and repair guidance is right next to them. This is exactly the form-specific version of Heuristic #9 "Help users recognize, diagnose, and recover from errors".Why: Reduce working memory burden — users should be able to correct the issue when they see the prompt, without having to recall where the error was.
| # | Guideline | Key points | Counterexample / Case |
|---|---|---|---|
| 1 | Prioritize inline validation | Prompt immediately after a field is filled (on blur), no need to go back and check; when relying on server-side validation, ensure information is clear and locatable | —— |
| 2 | Show success status for complex fields | Green checkmark for "username available", password strength meter; but do not overuse success markers for simple required fields | —— |
| 3 | Place error messages close to fields | Place next to or directly below the field; wording should be clear, polite, and offer constructive suggestions | Adobe: red color + icon next to the message draws attention |
| 4 | Use color to distinguish states | Red = error / orange-yellow = warning / green-blue = success; add semi-transparent background color to error fields to make them easy to locate in long forms | —— |
| 5 | Add icons or subtle animation | Icons (warning signs) help color-blind users locate errors; subtle pulsing can guide attention, but do not animate text (it interferes with reading) | —— |
| 6 | Use modals/confirmation dialogs sparingly | Modals interrupt flow and increase cognitive load; they are only suitable for simple or important non-ignorable errors | Gmail's modal prompt "Missing attachment" — simple and allows sending as normal, which is appropriate |
| 7 | Do not validate before input is complete | Wait until the user has finished filling and left the field before prompting; do not repeatedly pop up errors while the user is still typing | BestBuy: right after fixing the email field, it throws an error on the phone field before the user has even filled it |
| 8 | A validation summary cannot be the only error indicator | A top summary gives a global overview, but relying on it alone forces users to hunt through the whole form for errors; specific errors must also be displayed next to fields at the same time | SurveyMonkey: displays both top summary + errors below fields, which is correct |
| 9 | Do not use tooltips to report errors | Warning icons are hard to notice, and users must hover/click to see the content, adding extra steps | Facebook registration: errors use warning icons, users have to click each one to find out the problem |
| 10 | Offer extra help for repeated errors (>3 times) | Repeated errors on the same form = a deeper design problem; analyze error data, optimize the design, and provide support links | Quicken: provides a link to contact support for repeated errors |
1.3 Date-Input Form Fields
Date is one of the fields with the highest error rates — poor design not only leads to abandonment, but also causes booking failures due to incorrectly entered dates. First choose an input pattern, then follow a set of internationalization/fault-tolerance rules.
How to choose among the four input patterns:
| Pattern | What it looks like | Suitable for | Not suitable for / Counterexample |
|---|---|---|---|
| Calendar Picker | Displays a full-month calendar, imitating a wall calendar | Near-term dates (within one year);selecting date ranges is especially good | Requires repeated page flipping for far-future dates; Expedia uses two side-by-side months + blue highlighting to distinguish departure/return |
| Scrolling Picker | Mobile scroll wheel | Very near dates ("today") | Inefficient and time-consuming to scroll for large ranges; Todoist offers both scrolling + direct input |
| Split Dropdown | Three separate dropdowns for month/day/year | (generally not recommended) | Adds unnecessary steps, extra clicks + scrolling; DeviantArt is a counterexample |
| Direct Typing | Type directly | Distant past (birthdays) or future — the most basic and often most efficient method | Recommendation: always allow direct input even if other patterns are provided |
Date field design rules:
- Use lists for limited options: If available dates are few (e.g., delivery dates), list a short menu, gray out/hide unavailable dates; but do not use this method for more than 10 options. Case: Google Express.
- Do not enforce special character formats:
-/.space-separated formats should all be accepted, and leading zeros (09vs9) should not affect the result. Counterexample Priceline: rejects9-3-17, accepts09/08/17, but does not display format requirements. - Report errors reasonably: When encountering obviously invalid dates (
11/81/17), do not guess blindly; give feedback + resolution suggestions. - Remove unreasonable options: Birthdates should not be earlier than 130 years ago; return dates should not be earlier than departure dates or earlier than today — gray out/disable them.
- Save user input: Do not make users re-enter the same date in subsequent steps.
- Keep date ranges consistent: When departure shows "November–December", return should not suddenly jump to "December–January". Counterexample Southwest: after selecting departure
8-16-16, the return range quietly changes from "July–August" to "August–September", making misselection easy. - Support international formats:
10/11/2016Americans read October 11, Europeans read November 10 — this is the biggest ambiguity pitfall in date design. Countermeasures: split fields + labels, spell out month names. Positive examples: Tep Wireless / Bootstrap picker spells out month names; counterexamples: Eurostar does not label the format, Ctrip English version does not spell out month names.
2. Selection controls: Let users "choose" instead of "type"
The core tradeoff for selection controls is:option visibility ↔ screen space ↔ misoperation. The four controls below cover the full spectrum from "yes/no checking" to "continuous parameter fine-tuning".
2.1 Checkboxes
Core principle: Checkboxes = "independent on/off switches each", users can select 0, several, or all;radio buttons are for mutually exclusive choices where exactly one must be selected. Always use square shapes (rounded corners allowed), do not use circles — circles will be confused with radio buttons.
Three forms:
| Form | Use case | State |
|---|---|---|
| Standalone Checkbox | Single important confirmation: agree to terms, subscribe to marketing emails | Two states: checked / unchecked;default must be unchecked (default-checked promotional/legal items = deceptive design) |
| Checkbox List | Most common: select multiple items from a list (pizza toppings) | Items are independent, from 0 to all selected |
| Nested Checkboxes | Parent item with a group of child items (selecting passengers for check-in) | Three states: Select all / Select none / "Partially selected" (indeterminate); selecting a parent item = select/deselect all child items |
Checkboxes vs other controls comparison(to decide whether checkboxes are the right choice):
| Type | Example | Available options | Number of selectable items | Characteristic |
|---|---|---|---|---|
| Checkbox list | Selecting pizza toppings | Multiple | 0 to all | Each item is independent |
| Standalone checkbox | Agree to privacy policy | 2 | 1 | Mutually exclusive (on/off) |
| Nested checkboxes | Selecting boarding passengers | Multiple | 0 to all | Parent depends on children |
| Radio buttons | Selecting pizza crust | A small number | 1 | Mutually exclusive |
| Dropdown menu | Selecting title (Mr./Ms.) | Multiple | 1 | Mutually exclusive |
| Toggle switch | Turn dark mode on/off | 2 | 1 | Mutually exclusive+Takes effect immediately |
Usability rules: Labels must be clickable (expand the click area, touch target ≥1cm×1cm; Uber Eats uses horizontal lines to indicate the entire row is selectable);Use positive wording to avoid double negatives("Send marketing updates" > "Do not not send marketing updates"); list items should follow a logical order and be arranged vertically(easier to scan than horizontal layout); for multi-select scenarios, write "Select all that apply" (McDonald's surveys use helper text to distinguish checkboxes from radio buttons); when there is a minimum/maximum selection requirement, state it clearly and provide real-time feedback (DoorDash prompts "Up to 4"); for standalone checkboxes,ensure the semantics of the checked/unchecked states are clear—if they are unclear (e.g., the unchecked state of "Print as PDF" is ambiguous), use radio buttons or a dropdown instead.
2.2 Listboxes vs Dropdown Lists
Core principle: Both serve to "save space + reduce errors (only values within the list can be selected, ensuring data format)". The difference lies in visibility: listboxes spread options out for you to see, while dropdowns hide options and only show the current value.How to choose mainly depends on the number of options and whether you want to encourage users to make changes.
- Listbox: Consists of a container box + option list + label, supports single/multi-select (multi-select via Shift/Ctrl clicks, or with checkboxes, or dual listboxes with selectable items on the left and selected items on the right + sortable). Pros: see all options without clicking, high visibility, easy to overview and sort during multi-select. Cons: takes up space, multi-select operation is not intuitive, hard to see all selected items in long lists.
- Dropdown: Consists of a container box + downward arrow + list,single-select only. Pros: saves space, can set a default value, downplays alternatives (when the default satisfies most users), most familiar to users. Cons: requires a click to see options, scrolling is clumsy with many options, slower than typing for known values (e.g., birthday), too compact to be easily noticed, easy to close accidentally when the cursor drifts away.
Choose by number of options (key thresholds):
| Number of options | Recommendation |
|---|---|
| < 5 | Radio buttons / checkboxes (more intuitive) |
| 5–15 | Use a dropdown if space is tight; use a listbox if space is sufficient |
| > 15 | Prioritize listboxes for >15 options when users may not know the target value (can display more options, less scrolling); use dropdowns for very long known-value lists (e.g., country selection) |
| Multi-select required | Multi-select listbox with checkboxes |
| Sorting/overview required | Dual listbox that supports reordering |
| Default value needed and space is tight | Dropdown list |
Design law — Steering Law: The time it takes a user to move a cursor through a "tunnel" is faster when the tunnel is shorter and wider. Therefore, scrollable listboxes/dropdowns should limit the number of visible items and be made wide and short, not long and narrow (which causes more misoperations). Positive example: Sephora uses a multi-select listbox with checkboxes on the left for filtering, and a dropdown in the upper right for mutually exclusive sorting.
2.3 Parameter Input Controls: Sliders / Knobs / 2D Matrix
Core principle: Numeric parameters (price, quantity, opacity, brightness) need to balance exploration (coarse adjustment) and precision (fine adjustment). First distinguish discrete vs continuous, then use "linked controls" to cover both needs.
- Discrete controls: Limited options (toggles/checkboxes/radio buttons). Example: Kindle font size slider has only 12 steps, color mode radio has 3 options.
- Continuous controls: Any value within a range (sliders/knobs). Example: Kindle brightness, words-per-line slider.
| Control | Best for | Key points / limitations |
|---|---|---|
| Linear Slider | Clear range, exact value not important | Response delay ≤0.1 seconds;Do not use for scenarios requiring complex calculation/long loading(video rendering, big data filtering); narrow selection area makes precise values hard to select (Accot-Zhai Steering Law) |
| Range Slider | Setting upper and lower limits (price range) | Pair with visualizations such as histograms to avoid empty results; Kayak flight time slider overlays a price chart, orange line maps the selection |
| Virtual Knob | Naturally corresponds to angular parameters (audio panning) | Hard to rotate naturally with mouse/trackpad, often relies on hidden linear dragging that users cannot discover (GarageBand); for non-rotational parameters (compression value) use a horizontal slider instead |
| 2D Matrix | Adjusting multiple related parameters simultaneously (brightness + color curve) | Click to add breakpoints + drag to adjust curves; GIMP curves one control replaces multiple sliders |
Linked controls (coarse + fine adjustment): Slider for quickly browsing the range, text box for entering precise values,the two sync in real time; when dragging the slider, automatically move keyboard focus to the text box to make it easy to enter a precise value directly (Microsoft Office numeric stepper).Default values: Use a neutral value (100% zoom), provide a "Reset" option, mark the default position on the slider; counterexample: Apple Photos hides reset in the context menu, hard to find.
2.4 Input Steppers
Core principle: A stepper (
+/-two-segment button) is a relative control—each click adjusts the current value by a fixed step, unlike a text box where you enter an absolute value.Only suitable for discrete numeric values "with a clear default value that most people only adjust slightly"(number of travelers, number of bedrooms).
Pros: No keyboard needed (friendly to keyboardless devices, Kayak uses it to adjust traveler count), intuitive (horizontal -left +right, vertical +up -down; reverse for RTL languages such as Arabic), low interaction cost (Delta single-click to add a person < dropdown/text box), suitable when the exact value is uncertain (only need to decide to add or subtract, e.g., Ctrl++/- to adjust font size).
Limitations: Buttons are small and easy to tap accidentally (Sketch vertical stepper);not suitable for large adjustments(clicking from 1 to 50 is tedious).
Applicable vs not applicable table:
| Applicable | Not applicable |
|---|---|
| Has a commonly used default, most people make small adjustments | Wide range with no obvious default |
| Small adjustments / low precision requirement (number of bedrooms) | Continuous values where precision matters (price, distance) |
| Enough space to place buttons | Limited space, buttons easily become too small or crowded |
Design points: Set the value most people choose as default (1 traveler, 2 for restaurant reservations);do not use for continuous values(a fixed house price step of $100,000 limits precision, use a text box instead); clearly indicate the affected field (Dutch railway Ns.nl uses a dark blue underline to mark the currently adjusted time period); make buttons large enough (≥1cm×1cm on mobile, not too small on desktop either); prioritize horizontal layout (fewer accidental taps on mobile); use common symbols (+/- or up/down arrows);supplement with other input methods(direct text input + long press for continuous increment/decrement + keyboard arrows); clearly state step/unit/minimum and maximum values (Expedia grays out +).
III. Switches and Buttons: State toggling + preventing data loss from misoperation
3.1 Toggle Switch
Core principle: A toggle switch is the digital version of a light switch—two mutually exclusive states,has a default value, and most critically takes effect immediately(takes effect right after toggling, no need to click "Save/Submit" afterwards).This is the only hard difference between it and a checkbox.
| Control | Options | Number of user selections | Default value | Interaction effect |
|---|---|---|---|---|
| Radio buttons | Multiple | 1 | Yes | Takes effect after clicking "Submit" |
| Checkbox | Multiple | 0 to multiple | No | Takes effect after clicking "Submit" |
| Standalone checkbox | 1 | 2 (on/off) | Yes | Takes effect after clicking "Submit" |
| Toggle switch | 1 | 2 (on/off) | Yes | Takes effect immediately |
Design guidelines:① Provide immediate effect—counterexample: United Airlines iOS has no immediate result after toggling (should have used a checkbox), positive example: iOS Airplane Mode immediately changes the status bar icon after toggling; ② Concise and clear labels—prioritize key terms ("Email notifications" rather than "Would you like to receive email notifications?"), labels should clearly state "what happens when turned on", counterexample: Le Tote "Include non-maternity items?" is too vague, positive example: Google Calendar directly states the state; ③ Standard visuals—express state through position + color change, high contrast, be aware of cultural connotations (red mostly indicates warning, not suitable for "on"), counterexample: Windows 10 only shows "Off" description on the right which is confusing; ④ Stay consistent—do not mix toggles and radio buttons in the app (counterexample: Chase Bank iOS mixes them across pages, making behavior hard for users to predict).
3.2 Split Buttons
Core principle: A split button = one button with two zones.Label zone clicking directly executes the default action;Arrow zone clicking expands a menu to show other related commands. The difference between it and a "regular menu button": a menu button only opens the menu no matter where you click, with no default action.
Value: One-click access to the default option (saves steps), groups related commands together (reduces complexity).Cost: Novices don't realize there is something in the arrow zone (learning cost), the arrow target on touchscreens is too small and easy to tap accidentally.
Design points: ① The arrow zone must have clear visual separation (divider/color),don't only show the arrow on hover, keep it permanently visible; ② Use text labels to clearly state the default action ("Insert", "Reply"), don't only use icons; ③ Control menu content—fewer than< 10–12 items; sorting rule:< 5 items sort by frequency of use, > 5 items sort alphabetically(for predictability); avoid submenus as much as possible; display keyboard shortcuts in the menu to facilitate learning.
Persistent Split Button: A menu item the user has selected becomes the new default (after Windows Snipping Tool selects "Window snip", "New" defaults to window snip). Suitable for high-frequency repetitive tasks;do not use in environments with many novices—dynamically changing defaults break consistency and increase learning difficulty.Typical scenario: Toolbars with many commands in desktop applications.
3.3 Cancel vs Close
Core principle:
XWhether the icon means "Cancel (discard)" or "Close (save and exit)" is often unclear in interfaces—this ambiguity can cause users to lose unsaved work. Distinguishing between the two is the core battlefield of the "prevent data loss" heuristic. Especially when timers, audio playback, filter selections, or unsaved drafts are involved.
Three solutions:
| Solution | How to do it | Example |
|---|---|---|
| Ask for Confirmation | Show a confirmation dialog when pressing in a view with completed actions X Show a confirmation dialog when |
Lowes: clicking asks "Apply or cancel filters?"; Duolingo: confirm before closing an incomplete lesson to prevent lost progress.X Ask "Apply or cancel filters"; Duolingo: Confirm before closing an unfinished lesson to prevent lost progress.Drawback: Adds an extra step, and users don't know the consequence before pressing X Users do not know the consequences beforehand |
| Use Explicit Labels | Use "Cancel/Apply/Done/Clear" instead of the ambiguous (most direct and clear)X(Most direct and clear) |
Yelp "Cancel/Reset/Apply"; Etsy "Clear/Done" |
| Favor Close & Save | When space is limited and must be used, save progress by default + provide a separate "Cancel" button X, save progress by default and additionally provide a separate "Cancel" button |
Gmail:X saves draft and closes (hover tooltip "Save and close"); Glow Baby: pressing on a running timer only closes the view, timing continues in the background; pressing in paused state X Only closes the view, the timer continues running in the background; in paused state, press X triggers "Discard/Cancel" dialog |
Counterexample: Sephora—after selecting a free trial sample and clicking "Add", the interface looks like it has been added to cart (removable), but when the user clicks the upper-right
Xto close the popup it actually cancels the entire flow, the sample is not added to cart, and the user has to reselect.Why:Xwill not disappear from interfaces any time soon; designers must proactively disambiguate it—either with confirmation, text labels, or autosave.
IV. Copy and Login: Make links human-readable + Don't torture users with passwords
4.1 Better Link Labels: 4Ss
Core principle: A link is a promise—it must tell users "what you will see if you click" before they click. Users scan rather than read word-for-word, and links catch the eye more than body text, so link text must make sense on its own. Stick to the 4 Ss:
| S | Meaning | Failure case | Success case |
|---|---|---|---|
| Specific | Clearly state what you will see after clicking, don't be vague | Mailchimp fills the screen with "Learn more"—"I don't know what I'll see if I click, so I usually don't" | Microsoft"Watch the Microsoft Teams overview" |
| Sincere | Deliver on the exact expectation, don't mislead | Combadi "MORE INFO & BOOK" opens only a contact form—"This isn't what I wanted, how do I exit?" | Africa Odyssey directly labels it "CONTACT" |
| Substantial | Understandable even out of context, without relying on surrounding explanatory text | Emory University's "Frontiers of the brain" is incomprehensible on its own | GOV.UK"Marriage, civil partnership, and divorce" |
| Succinct | Remove filler words without sacrificing the first three qualities;Succinct ≠ short | "Learn more" is only 2 words but lacks any specificity, sincerity, or substance | GOV.UK's longer "Lasting power of attorney…" is effective instead |
Technique: links The first few words are most important(users scan only the beginning), so frontload key information.
4.2 Passwordless Accounts: OTPs & Passkeys
Core principle: Passwords are the biggest pain point in the login experience;OTP (one-time password) and Passkey make login and registration smoother, especially on mobile.Why (data):76% Users save passwords on their phones,17% use third-party password managers,10% or use both; but even with a manager, the experience is still dragged down by passwords (fields can't be recognized for autofill, generated strong passwords don't meet the site's special requirements).83% Users use biometrics at least occasionally (95% confidence interval 73%–87%).
Two types of passwordless authentication:
| Type | Mechanism | Advantages | Costs / Limitations |
|---|---|---|---|
| OTP (One-Time Password) | Temporary code sent via SMS or email / email "magic link" (Yummly) | No need to remember or manually enter complex passwords | Code delivery is slow on poor networks; email OTP requires switching apps to check email and may land in spam. On mobile,SMS OTP appearing at the top of the notification shade provides the best experience; on desktop, offer both SMS and email options |
| Passkey | During registration, the device creates and stores an encrypted credential; during login, an encrypted passkey is sent after fingerprint/face verification | No need to remember/store/enter anything,more secure(credentials are stored on the device, hard to phish) | Cross-device: a passkey created on iPhone requires scanning a QR code to log in on Android/Windows; seamless sync via iCloud between Apple devices (Kayak case study) |
Design recommendations:① Provide backup options——allow adding a regular password or biometrics on top of a passwordless account for multi-channel login; ② Give choices for OTP——let users choose whether to receive it via SMS or email (some people can only receive SMS on their current device); ③ Support multi-device for Passkeys——devices without a stored passkey can log in by scanning a QR code.Registration is still a pitfall: biometrics simplify login, but registration often gets stuck on unannounced complex password requirements (counterexample: MLB iPhone does not disclose password requirements).
V. Multi-step Processes and Tools: "Slicing" Complex Tasks into Steps
5.1 Wizards
Core principle: A wizard = splitting a complex process into multiple pages with step-by-step guidance, where each step may depend on the previous step's input, and users proceed linearly through "Next/Back/Cancel".Suitable for complex tasks done occasionally(tax filing, configuration, setup), reducing stress, cognitive load, and errors.Boundary with dynamic forms: Only count as wizards if the steps change based on user input (Fidelity shows different fields after asking "Are you an existing customer?"); forms with only real-time validation but fixed steps are still just forms (Live.com account creation).
Why wizards work: Only show the current task at a time (eliminates the overwhelming feel of long forms), show only relevant fields based on actual input (low cognitive load), step-by-step presentation reduces omissions (fewer errors), more screen space per step (less scrolling);Give each user the shortest path——branching logic shows only steps relevant to them (users without a credit card only see PayPal fields during checkout).
Limitations (when not to use them): Low input efficiency (more clicks than filling a form directly, more switching between keyboard and mouse); inconvenient cross-step reference (can't see previous inputs); hard to resume after interruption (exiting may lose information); dialog-style wizards block other content; restrict autonomy for expert users. Counterexamples: Word's reference manager's per-entry wizard is more laborious than bulk form filling; Mint's credit card recommendation wizard blocks the credit score the user needs to remember.
8 design recommendations: ① Use for novice/infrequent processes, provide shortcut alternatives for high-frequency tasks; ② Show a clear process model(list all steps on the side, gray out incomplete steps, highlight the current one, e.g., Veeam); ③ Enforce order(don't let users jump steps randomly; counterexample: Miniusa allows random selection causing memory load); ④ Use descriptive labels for buttons (show the specific next action, don't just say "Next/Previous"); ⑤ Support exiting mid-process and saving state (Mini's "Save and view" button is poorly positioned and easy to miss); ⑥ Make each step self-contained(don't rely on information elsewhere; counterexample: Expensify's wizard covers expense details); ⑦ Display assistance/help information in the wizard beside it rather than covering the main content (counterexample: Miniusa's instruction popups obscure the background); ⑧ Reuse user input (wizards for repeated use auto-fill previous values).
5.2 Onboarding Flows (merged note: original section title was State-Switch / Mute Button but the actual content is about onboarding flows)
Data merge note: The article in this batch titled "State-Switch Controls: The Infamous Case of the 'Mute' Button"has a title that does not match its content——the body actually discusses mobile app onboarding flows, and has nothing to do with "state-switch controls/mute buttons" (suspected original crawl/naming mismatch). It does not belong to the "forms and input controls" topic, but as a "multi-step guided flow" adjacent to wizards, its core points are lightly included here, and marked as a misfit at the end.
Core principle:Skip onboarding whenever possible——Onboarding adds interaction cost (even skipping requires extra taps), increases memory load, and research shows it does not necessarily actually improve task performance.When it is needed: When user information is required before launch (banks need account setup and verification), functionality is highly dependent on user preferences (diet apps customized by health status), or key workflows are unique (first-time mobile deposit). If unsure, test a no-onboarding version first.Three types of components: Feature promotion (more like marketing, better placed on the app store page rather than forced on first launch), personalization setup (content personalization is suitable for onboarding, e.g., fitness goals,visual personalization such as color schemes is not suitable——users haven't seen the interface so they can't choose; counterexample: Reflectly forces color scheme selection, positive example: Any.do puts it in settings), operational guidance (should not exist to compensate for design flaws; card-style tutorials are not recommended, instructional overlays should be given when the user first attempts the action rather than piled on at the start——counterexample: NOAA highlights all interactions on one screen making it overwhelming, positive example: Temple Run 2 gives real-time prompts during play).Conclusion: Keep onboarding as simple as possible; most apps should let users enter the interface directly; only give brief onboarding for complex or unique interactions.
5.3 Drag-and-Drop
Core principle: Drag-and-drop is "direct manipulation"——grouping/sorting/moving/resizing. It is intuitive and efficient, but error-prone, fatiguing, and has a learning cost(users must first anticipate that something can be dragged). Good drag-and-drop relies on three things: making it obvious that "this can be dragged" + clear feedback throughout grab/drag/drop + using magnetism to reduce precision requirements.
Three steps: Grab (tap/long press) → Drag → Release.
Design recommendations:
- Indicate draggability: Drag handle icons (three horizontal bars/two lines), cursor changes to hand or cross-arrow on hover, directional arrow prompts.
- Clear feedback: When grabbed, add shadow/contrast color/slight tilt/semi-transparent ghost image to make the object "float" up (Trello cards); dynamically highlight/change color/show preview on the Drop Zone, like a magnet attracting.
- Preview drop effect: Other objects make space, use short ~100ms animations + easing to simulate movement;Best trigger timing = when the center of the dragged object overlaps the target edge(too early is too sensitive, too late is too sluggish).
- Magnetism/Snapping: Objects automatically snap to targets when close; drop zones can be larger than the actual target (invisible boundary), e.g., file upload zones highlight and activate when a file approaches (Chrome tab dragging and docking).
- Mobile: Drop zones >1cm×1cm; use a few milliseconds of delay to distinguish "tap/swipe/grab";Provide haptic feedback(Instagram stickers vibrate once when grabbed and once when dragged to the trash); trade-off——Gmail desktop supports dragging and dropping emails, mobile uses menus instead (more steps but more accurate on small screens).
- Accessibility: Salesforce provides keyboard-accessible drag handles that report status and available actions to screen readers.
5.4 Accelerators
Core principle: Accelerators (shortcuts) are efficiency tools for expert users(keyboard shortcuts, gestures, voice commands),they can be ignored by novices and do not interfere with basic use. They implement Heuristic #7 "Flexibility and Efficiency of Use"—providing multiple paths for the same task.
Examples: Keyboard shortcuts (Ctrl+C/V), gestures (swipe to delete, double-tap to like, right-click), voice commands ("Start bedtime mode").
Discoverability strategies (let experts find them, don't scare novices): Progressive disclosure (novices do core tasks first, introduce accelerators after familiarity), contextual prompts (prompt the shortcut method at the right time after using the standard method, e.g., Slack prompts after reacting to a message), inline shortcut display (right-aligned in dropdown menus, Intercom), tooltips/hover (Dovetail shows shortcut G on hover, but not applicable to touchscreens), display complex accelerators in multiple places (macros/automation in menus + toolbars + settings), provide shortcut lists (Shopify's workflow-organized cheat sheet).
Best practices: Prioritize shortcuts for common tasks (copy/paste/save); use them moderately so they don't complicate the interface (Adobe InDesign hides custom shortcuts in the "Edit" menu for a small number of power users);Maintain consistency across platforms(double-tap to like is consistent on web and app, Instagram);Don't override common system shortcuts(copy/paste/select all/print); provide visual feedback;Error prevention——provide undo(Gmail pops a Snackbar with "Undo" after swipe-to-archive).
5.5 Calculators & Quizzes
Group three related articles together:User expectations(what they think) → Three types(what they output) → 12 design recommendations(how to design them).
Core principle: Calculators/quizzes let users trade their own information for personalized results——if they work well, they're treated as reliable information sources; if they're hard to use, they're abandoned. Users' mindset is exploratory and low-commitment: they enter approximate data first to see if the tool is useful.
User expectations (7 points):
- Definition: Calculator = self-contained tool, embedded in web pages, collects 2–7 inputs(Instacart cooking time); Quiz = usually 5+ inputs, often presented as a wizard (MyFitnessPal health plan 15+ inputs). Both essentially help with complex decisions.
- Users have low investment in initial output——they enter estimated values to evaluate the tool first, knowing the first version is imprecise so commitment is low.
- Users are reluctant to provide contact information——they prefer to try anonymously; especially being asked to register to see results after entering a lot of data makes them feel "tricked" (counterexample: Prose Haircare asks for contact info after 28 questions).
- More experienced users are harder to impress——if results don't match their experience, trust is lost immediately (become suspicious of HSA recommendations).
- More information should lead to more precise results——collecting detailed data but not using it, or not collecting enough, both make it feel inaccurate (counterexample: Princeton Review gives an overly broad career list after 24 questions).
- Users will use them forward and backward——Forward: enter down payment + credit score to see monthly payment; Reverse: set a desired monthly payment then adjust inputs. Tools should support both directions.
Three types (by output):
| Type | Output | Examples | Design key points |
|---|---|---|---|
| Conversion | Convert inputs into another format, no advice/explanation | Carbon footprint calculator (Carbonindependent), loan comparison (NerdWallet), time zones (World Time Buddy) | Present output according to user needs (time zones use color blocks to distinguish work/morning-evening/night) |
| Prediction | Estimate the future | Ovulation period, return on investment | Information must be accurate, especially in sensitive areas, to help non-expert users make correct decisions |
| Recommendation | Give personalized advice | Mint Mobile plan recommendations | Most useful when users need guidance or are uncertain; highly interactive |
| Combination | Conversion + prediction + recommendation | AARP Retirement Calculator (predicts savings + recommends savings/spending strategies), Compass exam score conversion + recommendation on which exam to prioritize | Satisfies information needs while delivering additional business value |
12 design recommendations:① Optimize for SEO——Include the keywords "calculator/quiz/estimator" in the title (many users arrive via search); ② Embed directly in the web page(do not use pop-ups/standalone pages) and ensure fast loading; ③ Support multiple input quantities——Only require mandatory fields, allow dropdowns/sliders for approximate values or text boxes for precise values (Ramsey insurance calculator only requires selecting an income range, with the wording "a rough number is fine"); counterexample: an insurance calculator that did not allow selecting multiple insurance types, making users feel it was unreliable; ④ Do not force registration(all users of the Ohio State University cancer risk calculator selected "continue as guest"); ⑤ Display results instantly on the website(do not require registration or waiting for an email; counterexample: Princeton Review required registration after users answered 24 questions); ⑥ Make it easy to adjust inputs and reset(support repeated trials; counterexample: Clare.com cleared subsequent selections when users changed an earlier choice); ⑦ Explain the purpose of inputs(users are willing to provide data only when they understand why it is needed; Mint Mobile explains why it asks whether users have paid off their phone bills); ⑧ Help users understand input items(provide descriptions/examples next to fields for unfamiliar items; counterexample: the American Heart Association's "wall of text" overwhelmed users); ⑨ Present output in a meaningful context(Voya maps spending to the "needs/wants/savings" framework); ⑩ Avoid misleading default values(counterexample: Google's mortgage calculator kept the default property tax value unchanged after the state was changed, which could overestimate monthly payments by hundreds of dollars); ⑪ Consider making the algorithm public(increases trust and improves transparency); ⑫ Do not assume AI is necessary——Users care about reliability and practicality, not whether AI is used.
Sourced from NNGroup Topics / Design Patterns - Design Patterns (Forms and Input subset, 19 patterns). This subset complements the Navigation/Search and Feedback/Dialog subsets; the "foundation" of design principles (visibility of system status/user control/error prevention/recognition over recall/flexibility and efficiency) can be found in NNGroup Usability Testing and the 10 Usability Heuristics (full list of 10 heuristics · application to complex applications · user pleasure hierarchy · testing methods: 5-user rule/recruitment/remote testing/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample errors/competitive evaluation); see also NNGroup Interaction Patterns · Navigation and Search (25 patterns · global navigation/local navigation/breadcrumbs/hamburger menus/context menus/17 menu guidelines/tabs/accordions/footers/sticky headers/table of contents/in-page links/spatial memory/site search/SERP/filters/pagination/tree testing) / NNGroup Interaction Patterns · Feedback · Dialogs · Notifications · Loading · Prompts · Empty States · Data Presentation (15 patterns · when to use/how to choose/counterexamples). Merge notes: Two error-reporting articles ("10 Design Guidelines…" and "How to Report Errors…") cover the same set of 10 guidelines, which have been deduplicated and merged into §1.2; the title of "State-Switch Controls / 'Mute' Button" does not match its body text (the body actually covers onboarding flows), so it is lightly included as a misfit in §5.2. Images/videos/original documents are retained in sources.
Sources and related materials
- NNGroup Interaction Patterns · Navigation and Search (25 patterns · global navigation/local navigation/breadcrumbs/hamburger menus/context menus/17 menu guidelines/tabs/accordions/footers/sticky headers/table of contents/in-page links/spatial memory/site search/SERP/filters/pagination/tree testing)
- NNGroup Interaction Patterns · Feedback · Dialogs · Notifications · Loading · Prompts · Empty States · Data Presentation (15 patterns · when to use/how to choose/counterexamples)
- NNGroup Usability Testing and the 10 Usability Heuristics (full list of 10 heuristics · application to complex applications · user pleasure hierarchy · testing methods: 5-user rule/recruitment/remote testing/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample errors/competitive evaluation)