Problem
A decision point is reached within a process where the user must confirm an action, or choose between a small number of disparate (and usually exclusive) choices.
Solution
Try to avoid presenting these conditions to the user. Except for error or guard conditions such as Exit Guard systems can often be designed for avoid explicit choices. For example, when opening a Messaging compose screen, instead of presenting a Confirmation dialog asking whether they intend to compose an MMS or SMS, just open a compose screen with attachment options. If an attachment is chosen, it becomes an MMS. Else, it's an SMS. The choice is still made by the user, but implicitly by actions and choices (selection of the attachments) they needed to make anyway.
Sometimes, these cannot be avoided, and user input cannot be divined contextually. If so, present choices contextually -- usually as a modal dialogue -- simply and clearly communicate the consequences of the choices.
Variations
Though many display methods are possible, all will be modal dialogues of some sort. For more details on these, see variations under Pop-Up.
Three key variations exist:
A single choice is fairly rare, and is only used to inform the user. For example, a fatal error has occurred, and the handset must be restarted. Instead of just doing so, it may be helpful to tell the user that the condition has been reached, so a Confirmation dialogue is presented, and a single "Restart" button is presented.
By far the most common is two or three choices. This is the maximum number readily comprehended at a glance and presents enough options for most required decisions. Examples of three choices are when exiting with unsaved documents, offer to return to work, save the work and exit and exit without saving. See Exit Guard for more discussion of these sorts of conditions.
In some cases, a larger number of choices must be presented. These will generally be as a list of selections in the dialogue.
Interaction Details
The Confirmation pattern involves an error or choice that stops the process. Such choices should not be avoidable, but should be contextual to make it clear what application, or process they will effect. These should therefore be modal Pop-Up dialogues almost always. See that patterns for additional details.
Whether two or three choices is convenient or requires a non-standard UI is dependent on the OS paradigms. When the device OS uses Softkeys or softkey-like on-screen buttons, then two choices with the dialogue docked to the edge with the buttons is the simplest way to present a small number of options. However, it (usually) limits the options to two.
If additional selections are required, they may be loaded in any way needed, such as buttons in the Pop-Up, as pick lists, etc. Use the Softkeys for primary supporting actions, such as Cancel. In the example above of exiting with unsaved documents, the choices to exit without saving and save documents would be in the dialogue, and the option to return to the application would be labeled "Cancel" and be the Softkey conventionally used for this.
Avoid disregarding Softkeys entirely, for consistency of the interface.
Presentation Details
When the Pop-Up appears, use other methods to notify the user of the stop in process, such as audio and/or vibration. Follow current system volume settings for the notification. Mobiles are used in quick glances, so the user may not notice such a stop in process for minutes or hours unless informed via a non-visual channel.
If the Confirmation action occurs while an application is running in the background, use any available notification method installed with the OS to bring this to the front. If the only method is a Pop-Up dialogue interrupting the in-focus process, use this carefully. Trivial processes, such as a game crashing, do not need to interrupt phone calls.
the things where you don't label buttons yes or no. --- label selections so they can be understood without prior knowledge or reading instructions. E.g. never "yes" "no" buttons, but "delete" or "save" and similar actionable, declarative, free-standing, choices... Handsets are glanceable...
Antipatterns
Do not over use the single choice variation. For example, if an application must quit and a Confirmation dialogue is useful, a dual choice would usually be better. Offer options to just quit or to quit and restart the same application immediately.
Carefully consider whether a Confirmation dialogue is the right pattern any time more than three choices are offered. It may be a natural part of the process. The use of the modal dialogue implies exceptional conditions or errors so should only be used when needed.