feedback-and-status

Name: feedback-and-status
Author: Owl-Listener

82stars25forks

How to install feedback-and-status?

owl-listener/inclusive-design-skills/feedback-and-status

$npx -y skills add Owl-Listener/inclusive-design-skills --skill feedback-and-status

Installs into the current project.

Summary

Design feedback and status communication that works across senses — visual, auditory, and haptic. Use when designing loading states, success messages, progress indicators, notifications, alerts, or any system response to user action. Triggers on: feedback, status, notification, a

Files · 1

View on GitHub

SKILL.md

1	# Feedback and Status Design
2
3	Design system feedback that reaches every user — regardless of whether
4	they can see the screen, hear audio, or feel vibration. No single
5	sense should be the only channel.
6
7	## Core Principle
8
9	Never communicate status through one sense alone. What happens if the
10	user can't see it? Can't hear it? Can't feel it?
11
12	## The Multi-Channel Rule
13
14	Every piece of feedback should work through at least two channels:
15
16	\| Feedback type \| Visual \| Text \| Sound \| Haptic \|
17	\|--------------\|--------\|------\|-------\|--------\|
18	\| Success \| Green tick \| "Saved successfully" \| Confirmation tone \| Short vibration \|
19	\| Error \| Red highlight \| Specific error message \| Alert tone \| Double vibration \|
20	\| Loading \| Spinner/bar \| "Loading..." \| None (silence) \| None \|
21	\| Warning \| Yellow banner \| Warning text \| Optional tone \| Optional vibration \|
22
23	Screen readers are a critical third channel — all visual feedback must
24	be announced to assistive technology.
25
26	## Design Patterns
27
28	### Don't Rely on Colour Alone
29	- Red/green is invisible to 8% of men with colour vision deficiency
30	- Always combine colour with: icon, text label, pattern, or position
31	- Error states: red + error icon + text description
32	- Success states: green + tick icon + text confirmation
33	- Test: does this still communicate the same thing in greyscale?
34
35	### Immediate Feedback
36	- Button press: visual change within 100ms (pressed state)
37	- Form submission: loading indicator within 1 second
38	- Completion: success message within 2 seconds of finishing
39	- Error: highlight the specific field, not just a banner at the top
40
41	### Persistent vs. Transient Feedback
42	- Transient (toast/snackbar): only for non-critical confirmations.
43	Show for at least 5 seconds. Include a way to review missed messages.
44	- Persistent (inline): for errors, warnings, and anything the user
45	needs to act on. Never auto-dismiss error messages.
46	- Screen reader users miss transient messages — use aria-live="polite"
47	for non-urgent updates, aria-live="assertive" for critical alerts.
48
49	### Progress Communication
50	- Determinate progress (known duration): show percentage or step count
51	- Indeterminate progress (unknown duration): show spinner with
52	text like "Loading your results..."
53	- Long processes (over 10 seconds): add estimated time remaining
54	- Very long processes: allow background processing with notification
55	on completion
56
57	### Status Without Vision
58	- All status changes must be announced to screen readers
59	- Use aria-live regions for dynamic content updates
60	- Don't rely on visual position alone to convey status
61	(e.g., a moved item in a kanban board needs a text announcement)
62	- Error messages must be programmatically associated with their
63	field (aria-describedby)
64
65	## Assessment Questions
66
67	1. Is colour ever the only indicator of status?
68	2. Can a screen reader user perceive every status change?
69	3. Are error messages persistent until resolved?
70	4. Do transient messages display long enough to be read?
71	5. Does every user action produce perceivable feedback?

People who liked this also viewed

6 picks

Type

feedback-and-status

82stars25forks

View on GitHub

How to install feedback-and-status?

owl-listener/inclusive-design-skills/feedback-and-status

$npx -y skills add Owl-Listener/inclusive-design-skills --skill feedback-and-status

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Feedback and Status Design
2
3	Design system feedback that reaches every user — regardless of whether
4	they can see the screen, hear audio, or feel vibration. No single
5	sense should be the only channel.
6
7	## Core Principle
8
9	Never communicate status through one sense alone. What happens if the
10	user can't see it? Can't hear it? Can't feel it?
11
12	## The Multi-Channel Rule
13
14	Every piece of feedback should work through at least two channels:
15
16	\| Feedback type \| Visual \| Text \| Sound \| Haptic \|
17	\|--------------\|--------\|------\|-------\|--------\|
18	\| Success \| Green tick \| "Saved successfully" \| Confirmation tone \| Short vibration \|
19	\| Error \| Red highlight \| Specific error message \| Alert tone \| Double vibration \|
20	\| Loading \| Spinner/bar \| "Loading..." \| None (silence) \| None \|
21	\| Warning \| Yellow banner \| Warning text \| Optional tone \| Optional vibration \|
22
23	Screen readers are a critical third channel — all visual feedback must
24	be announced to assistive technology.
25
26	## Design Patterns
27
28	### Don't Rely on Colour Alone
29	- Red/green is invisible to 8% of men with colour vision deficiency
30	- Always combine colour with: icon, text label, pattern, or position
31	- Error states: red + error icon + text description
32	- Success states: green + tick icon + text confirmation
33	- Test: does this still communicate the same thing in greyscale?
34
35	### Immediate Feedback
36	- Button press: visual change within 100ms (pressed state)
37	- Form submission: loading indicator within 1 second
38	- Completion: success message within 2 seconds of finishing
39	- Error: highlight the specific field, not just a banner at the top
40
41	### Persistent vs. Transient Feedback
42	- Transient (toast/snackbar): only for non-critical confirmations.
43	Show for at least 5 seconds. Include a way to review missed messages.
44	- Persistent (inline): for errors, warnings, and anything the user
45	needs to act on. Never auto-dismiss error messages.
46	- Screen reader users miss transient messages — use aria-live="polite"
47	for non-urgent updates, aria-live="assertive" for critical alerts.
48
49	### Progress Communication
50	- Determinate progress (known duration): show percentage or step count
51	- Indeterminate progress (unknown duration): show spinner with
52	text like "Loading your results..."
53	- Long processes (over 10 seconds): add estimated time remaining
54	- Very long processes: allow background processing with notification
55	on completion
56
57	### Status Without Vision
58	- All status changes must be announced to screen readers
59	- Use aria-live regions for dynamic content updates
60	- Don't rely on visual position alone to convey status
61	(e.g., a moved item in a kanban board needs a text announcement)
62	- Error messages must be programmatically associated with their
63	field (aria-describedby)
64
65	## Assessment Questions
66
67	1. Is colour ever the only indicator of status?
68	2. Can a screen reader user perceive every status change?
69	3. Are error messages persistent until resolved?
70	4. Do transient messages display long enough to be read?
71	5. Does every user action produce perceivable feedback?

People who liked this also viewed

6 picks

Type