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 these state. Except for error or guard conditions (discussed below, LINK) usually can avoid with better design. E.g. opening a Messaging compose screen, instead of asking whether composing 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.
Sometimes, these cannot be avoided, and user input cannot be divined contextually. If so, present choices contextually, usually as a modal dialogue, simply and with the consequences of the action.
Variations
Interaction Details
Mostly modal dialogues.
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...
When the device OS uses Softkeys or softkey-like on-screen buttons, there is no need to restrict to only the (usually two) actions available. If additional actions 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. Avoid disregarding Softkeys entirely, for consistency of the interface.
Presentation Details
vibrate or beep if it is possible the
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