Secondary button
Secondary buttons are regular buttons used for non-primary actions. If you are uncertain which button type to choose, secondary buttons are always the safest choice.
components/buttons
33 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Primary button
Primary buttons emphasize completion and recommended actions. A button area should use a maximum of one primary button.
Text button
Text buttons are weakened buttons that use a lighter button style, suitable for scenarios requiring large-area button display, such as action columns in table components.
Icon button
Icon buttons provide visual cues and help users understand the button's function without reading text, enabling more efficient interface usage. Pure icon buttons must have a Tooltip that explains the button's meaning. Icon buttons should be used when you need to display many buttons in a small space.
Icons inside buttons
Adding icons to buttons provides supplementary explanation of the button's meaning and improves button recognition efficiency.
Button emphasis levels
Regular button types present different emphasis levels, allowing designers to vary button types appropriately based on the context.
Multiple primary buttons pitfall
Do not place more than one primary button in a button area.
Multiple icons in buttons pitfall
Do not place two icons inside a single button.
Dashed button
Dashed buttons are used to guide users to add content to an area.
Danger button
Danger buttons warn users that the action carries risk, typically using red color to alert. When the user's primary intent is to delete, use red to indicate the operation has risk. When the system does not recommend a delete operation, the cancel button can be set as the primary button instead.
Ghost button
Ghost buttons are placed on complex or deep backgrounds to avoid the button disrupting the overall integrity of the background. Styles can be flexibly customized in these scenarios.
Call to action button
Call to action buttons appear independently and function like the computer telling the user to follow along, with an imperative tone to click. They typically appear on landing pages or guiding scenarios. The button can be expanded to match the width of its parent area. Only one call to action button is recommended per screen space.
Button area definition
A button area is the designated space for placing buttons, and can contain multiple buttons.
Button area following content
Button areas should follow the controlled content. Placing the button area within the user's browsing path makes it easier for users to discover.
Button area in toolbar
In a toolbar, the button area should be placed on the right side to control the scope of content affected by the toolbar.
Page structure regions for button placement
Pages, cards, and groups of information can be abstracted into three regions: Header (title, summary, and navigation), Body (specific content), and Footer (supplementary information and toolbars). Button placement in different regions conveys different meanings.
Footer button area use cases
To prevent footer toolbar misuse, use footer button areas only in two scenarios: (1) Object detail pages where you are advancing the object's progress, such as approval flows with actions like approve or reject, and (2) Exceptionally complex form pages where form content is complex enough to be split across multiple cards.
Button order principle
Recommended operations are the starting point for reading. Folded content always stays on the far right. Button placement order should follow conversation habits: prioritize asking about operations the user might need to perform or that you want the user to perform, and finally provide operations with risk. Consider directional meaning—for example, buttons with return meaning should be placed on the left to suggest going back.
Button group layout
When multiple buttons form a group, arrange them together. Connected button groups can be visually confused with toggle buttons, so avoid this design pattern.
Toolbar button ordering logic
When there are many operation types in a toolbar, prioritize fixing positions for content that changes less frequently. For table toolbars, arrange buttons in this order: (1) Business logic operations like edit, create, publish, save, cancel, undo; (2) View control operations like fullscreen, table density, zoom, layout control; (3) Other operations like refresh, share, settings; (4) Overflow operations that are collapsed, collapsing from right to left in responsive design.
Button grouping strategy
When there are too many buttons to arrange, group related actions together and use similar visual design. When one button is the primary action, it can still be emphasized with primary button styling. Prefer using spacing to differentiate groups; vertical divider lines can be used to differentiate visually similar button groups when grouping is necessary.
Button text requirements
Button text must clearly convey what the system will execute when the user presses the button. Use verbs (except for dropdown buttons). Text should be closely related to context and use concise language.
Button text optimization strategies
Ant Design components use default 'Confirm / Cancel' text, but you can optimize button text by: (1) describing the task result such as 'Publish', 'Login', 'Register'; (2) when the primary action is also negation in meaning, emphasize the consequence, such as 'Are you sure you want to delete it? Delete / Cancel'.
Button verb requirement
Button text must use action verbs. Dropdown buttons are an exception to this requirement.
Primary button styling
Button (primary) is the single dominant action per screen. It has solid primary (#1677FF) fill with white text, is 32 px tall, has 6 px radius, and 0 15px padding. Hover state lightens the fill to #4096FF. Active state darkens the fill to #0958D9. Do not stack two primary buttons in one decision.
Three emphasis levels for buttons
Ant Design button emphasis levels are: primary (solid fill, dominant action), default (secondary action with transparent background and outline), and other states for specific use cases. Primary is for the single most important action per screen; do not stack multiple primary buttons.
Default button styling
Button (default) is for secondary actions. It has transparent background on a white surface with dark text (#1F1F1F), is 32 px tall, has 6 px radius, and 0 15px padding. Hover changes text color to #4096FF and the border tints to match.
Design don't: stack primary buttons
Do not stack two primary-colored buttons on the same surface. Pick one and demote the rest to default.
Button reversed hover and active colors for color in dark theme
Button's hover and active colors were reversed for the color property in dark theme. This was fixed in version 6.3.0 with PR #56872.
Button border size follows Design Token lineWidth
Button's border size should follow the Design Token lineWidth property. This was fixed in version 6.3.0 with PR #56683.
Button custom disabled state background color
Button now supports custom default and dashed type button background color in disabled state.
Button solid variant default color support
Version 6.4.0 added default color support for Button solid variant.
Button variant and color refactored to CSS variables
Button component's `variant` and `color` styles have been refactored to use CSS variables to reduce bundle size.