Providing User Feedback
Intro#
Our users understand our environment by interacting with it, measuring how it responds and then learning something. For every action there is a reaction, or user feedback. A decision can then be made based on that feedback.
Usage / Best Practices#
- For each action our user performs, we should relay a response back to them.
- The feedback must be visible proximate to where the action was taken, and the user is focused.
- Feedback should be provided at a speed which is natural. When things happen too fast, it is not what we expect and therefore it does not feel natural. If feedback is too slow, we lose interest and/or feel frustration.
Time Scales#
- 0.1 seconds is the minimum amount of time a user should wait if we want them to feel that their action is causing something to happen on the screen. This includes button state changes, expandable menus, changing radio button option, selecting checkboxes etc.
- 1 second is the longest a user should wait without some form of feedback that the computer is completing a task. (Eg loading data)
- 10 seconds is the maximum amount of time a user should have to wait before the computer has completed a task. (Eg loading data)
Feedback Components#
Alert#
- Use for page level success or failure messages, as well as information or warnings.
- Use for card or modal level success or failure messages, as well as information or warnings.
- Use for form errors to display a summary if multiple errors have occured. See Error and Warning Messages
Drawer#
WIP- add high-level info here.
Message#
WIP- add high-level info here.
Modal#
Use when a user must complete an action before they can continue with their workflow, an action is severe or will result in a loss of data, or to show additional information in context.
Notification#
WIP- add high-level info here.
Popconfirm#
Use when we recommend the user make a different decision than the one, they are about to make, but we still want to give them the option of moving forward, or you do not want to completely disrupt the user flow with a non-critical decision.
Progress#
WIP- add high-level info here.
Result#
Used to provide users with feedback results to actions done on a page, often specifically server errors.
Skeleton#
Use to provide “loading” feedback using a low fidelity depiction of the UI before the content appears.
Loading Spinner#
Use to provide “loading” feedback using a low fidelity depiction of the UI before the content appears.