VOCABULARY / ENTRY
Inclusive Design
inclusive-design
Actively recognize exclusion, learn from human diversity, and extend solutions for specific constraints to benefit more people.
Interactive specimen · Fictional product FIELDNOTES
Choose a route
Use touch or Tab and Enter. Route information is also available as text.
Selected: Short route
This only demonstrates alternative input and clear information. It does not validate every person's experience.
Recognizing it
- Recognizing mismatches between people and environments
- Offering different ways to achieve a goal
- Involving affected people in validation
Concept boundary
This is not a few accessibility switches added before delivery. Different people need to participate in understanding, design, and validation.
When to consider it
- Defining intended users and core tasks
- Permanent, temporary, or situational constraints affect use
When to be cautious
- Claiming a product includes everyone based on one specimen
- Treating one person's preferences as everyone's needs
Tradeoff
It requires contact with real people and contexts; component checks cannot replace participatory validation.
Conditional rules · Editorial advice
When Only automated checks have been completedMustDo not claim every person's experience has been validated.
When Designing a new input or feedback methodRecommendedConsider alternative ways to operate it and involve affected people in validation.
Related entries
Calm Technology ↗Works with · Designing status notifications
Consider attention and different ways of perceiving information together.
Recognition Rather Than Recall ↗Realized by · Reducing reliance on memory
Visible, readable options are one concrete strategy.
Sources and what they support
Microsoft · Inclusive Design ↗
The method emphasizes recognizing exclusion, learning from diversity, and solving for one while extending to many.
Retrieved: 2026-09-15Definitions reference these sources. Digital specimens, selection advice, relationships, and recipes are editorial work and have not been validated through user research.
Type extensions and implementation notes
Capability tags describe this specimen only; verify the implementation again in a real product.
{
"values": [
"Participation",
"Diversity",
"Recognizing exclusion"
],
"tension": "Shared solutions versus individual differences",
"questions": [
"Who would this default interaction exclude?",
"Could the same goal be achieved another way?"
]
}Full Agent entry JSON
{
"id": "inclusive-design",
"type": "philosophy",
"name": {
"zh": "包容性设计",
"en": "Inclusive Design"
},
"aliases": [
"包容设计"
],
"granularity": "experience",
"intents": [
"include-users",
"reduce-exclusion"
],
"tags": [
"diversity",
"differences in ability",
"temporary constraints",
"participation",
"accessibility"
],
"definition": "Actively recognize exclusion, learn from human diversity, and extend solutions for specific constraints to benefit more people.",
"boundary": "This is not a few accessibility switches added before delivery. Different people need to participate in understanding, design, and validation.",
"signature": [
"Recognizing mismatches between people and environments",
"Offering different ways to achieve a goal",
"Involving affected people in validation"
],
"when": [
"Defining intended users and core tasks",
"Permanent, temporary, or situational constraints affect use"
],
"when_not": [
"Claiming a product includes everyone based on one specimen",
"Treating one person's preferences as everyone's needs"
],
"tradeoff": "It requires contact with real people and contexts; component checks cannot replace participatory validation.",
"comparison": {
"focus": "Who can participate and achieve the goal",
"mechanism": "Recognizing exclusion, learning from diversity, and extending solutions",
"cost": "Requires participation from diverse people"
},
"sources": [
{
"id": "microsoft-inclusive",
"title": "Microsoft · Inclusive Design",
"url": "https://inclusive.microsoft.design/",
"claim": "The method emphasizes recognizing exclusion, learning from diversity, and solving for one while extending to many.",
"checkedAt": "2026-09-15",
"archive": {
"lookupUrl": "https://web.archive.org/web/20260915*/https://inclusive.microsoft.design/",
"status": "available",
"checkedAt": "2026-09-15T16:52:31.168Z",
"jobId": "spn2-332d4dfe0ac0ccd46a65e0083dc1d0e80ef177d5",
"url": "https://web.archive.org/web/20260915165359/https://inclusive.microsoft.design/",
"timestamp": "20260915165359"
}
}
],
"relations": [
{
"target": "calm-technology",
"kind": "composes_with",
"condition": "Designing status notifications",
"reason": "Consider attention and different ways of perceiving information together.",
"basis": "editorial"
},
{
"target": "recognition",
"kind": "realized_by",
"condition": "Reducing reliance on memory",
"reason": "Visible, readable options are one concrete strategy.",
"basis": "editorial"
}
],
"rules": [
{
"when": "Only automated checks have been completed",
"instruction": "Do not claim every person's experience has been validated.",
"strength": "must",
"basis": "editorial"
},
{
"when": "Designing a new input or feedback method",
"instruction": "Consider alternative ways to operate it and involve affected people in validation.",
"strength": "recommend",
"basis": "editorial"
}
],
"philosophy": {
"values": [
"Participation",
"Diversity",
"Recognizing exclusion"
],
"tension": "Shared solutions versus individual differences",
"questions": [
"Who would this default interaction exclude?",
"Could the same goal be achieved another way?"
]
},
"demo": "inclusive-design",
"version": "0.1.0",
"editorialStatus": "sample-reviewed",
"requirements": [],
"demoCapabilities": [
"keyboard",
"reduced_motion"
],
"implementationNote": "Capability tags describe this specimen only; verify the implementation again in a real product.",
"searchTerms": [
"多样性",
"能力差异",
"临时限制",
"参与",
"无障碍"
]
}