Problem

Within any context, an action must be initiated, information submitted, or a state change carried out.

Solution

Use a Button to initiate an immediate action. A button is are not simply a "more important" Link, and should not act as such. Button-like action behaviors may be initiated with an Icon and label pair, if space or other layout or style considerations require it.

Variations

Standalone - does something out of the blue...

In-conjunction. With radios, checks or any other user inputs or controls, to commit these user selections. Within websites, buttons are used to submit (or cancel submission of) forms to remote servers.

Delayed input. Ellipsis indicate more info is needed, usually in a modal dialogue.

Interaction Details

MS: The default command button is invoked when users press the Enter key. It is assigned by the developer, but any command button becomes the default when users tab to it.

Inactive! Use to avoid errors...

Presentation Details

Buttons must be very easy to see and activate (especially for touch/pen devices); they are usually about twice the height of the default page text, to provide room around the label. Smaller Buttons can be used for less-important or less-used items, but should never be smaller than about 120% of the vertical size of the smallest text. Consider click target sizes for touch and pen devices, and do not make selection areas smaller than 10 mm.

The width may be fixed, or vary based on the size of the text. Try not to have too much empty space. Vertical size must be the same for equivalent actions. An "OK" and "Cancel" pair, for example, must be the same vertical size.

Buttons should generally appear to be raised above the page slightly. When a button is selected, it should appear to have been pressed and be level with or below page level slightly. Buttons are momentary-contact items, and this activation display should cease when the user click action ceases.

For scroll-and-select devices, the button in focus will have a thicker border or other indicator. Inactive buttons must be indicated by being "grayed out." Be sure to select a sufficiently-saturated background and high enough label-to-background contrast that graying out is clear.

Use the writing style already defined for the rest of the OS, your application or your site. Be consistent with capitalization in all Buttons. Be clear about terminology, and avoid labels that require reading. Rarely should buttons say "Submit" or "OK." Descriptive, free-standing labels like "Connect" are always better.

For additional clarity, consider using icons inside the button. Use the most obvious graphic possible, with multiple encoding (e.g. a green check for submit and a red X for cancel). If graphics are not supported, or cannot be relied on (as with low-end web),

⊗ ⊗ ⊗ √ √ √

Icons inside the button... mention the text icons which port across all of them. Use a couple examples, like the "check" and "X" size, indicator of priority. Still like BOA old ones with color/shape icons alongside. Apple arrowed button bars are good examples of this...

Antipatterns

Carefully consider whether a series of buttons should be used to make a choice. A more suitable solution is often another type of selection (such as radio buttons) with the Button used to commit the selection. This also allows adding other behaviors, such as a checkbox to indicate the selection should be the default from then on.

Avoid making the default button perform an unrecoverable, destructive action. Users must make deliberate choices instead. See Exit Guard for more on this behavior.

Avoid color schemes that can be misconstrued as being "grayed out," and inaccessible.

Examples