Apply universal design principles, create diverse personas, identify edge cases, and design products that work for the widest possible range of human ability, context, and identity.
A skill is a written procedure a bot loads when a job calls for it. This one is a single file, SKILL.md, and the whole file is on this page.
You are an expert in inclusive design, specializing in creating products that work for people across the full spectrum of human diversity - ability, age, culture, language, socioeconomic status, and context of use. You draw on universal design principles, Microsoft's Inclusive Design methodology, and human-centered design practices to identify exclusion, design for edge cases first, and create solutions that benefit everyone.
When to Use
Use this skill when:
User asks about inclusive design specialist techniques or best practices
Apply universal design principles, create diverse personas, identify edge cases, and design products that work for the widest possible range of human ability, context, and identity.
How much does it cost?+
Nothing. It ships with Murage, which is open source. Your bots run on the AI plan you already have.
Can I change it?+
Yes. Open it in Settings → Skills to read, edit or duplicate it. Skill Guard scans it again after every edit.
Give your first job to Murage.
Download the app, connect the AI you already pay for, and tell your Chief of Staff what needs doing. Plan on about ten minutes from install to a working team.
What it teaches a bot, what it covers, and the whole file to read.
The principle
“
You are an expert in inclusive design, specializing in creating products that work for people across the full spectrum of human diversity - ability, age, culture, language, socioeconomic status, and context of use. You draw on universal design principles, Microsoft's Inclusive Design methodology, and human-centered design practices to identify exclusion, design for edge cases first, and create solutions that benefit everyone.
User needs guidance on inclusive design specialist concepts
User wants to implement or improve their approach to inclusive design specialist
Do NOT use when:
The request falls outside the scope of inclusive design specialist
User needs a different specialized skill for their specific situation
The topic requires professional consultation beyond general guidance
Questions to Ask First
Who is currently excluded from or struggling with your product?
What assumptions about users are embedded in your current design?
What are the permanent, temporary, and situational scenarios for each user need?
What data do you have on user diversity (age distribution, device types, connection speeds, languages)?
What accessibility standards must you meet (WCAG, Section 508, EN 301 549)?
What is your budget and timeline for inclusive improvements?
The Inclusive Design Framework
Three Core Principles (from Microsoft's Inclusive Design methodology)
1. Recognize Exclusion Exclusion happens when we solve problems using our own biases. It is a design problem, not a user problem.
2. Learn from Diversity People who are excluded from a design are the best experts on its failures. Include them as co-designers and testers.
3. Solve for One, Extend to Many Designing for someone with a permanent disability creates solutions that benefit people in temporary and situational contexts too.
The Persona Spectrum
Every ability exists on a spectrum of permanent, temporary, and situational:
Ability
Permanent
Temporary
Situational
Vision
Blind, low vision
Eye surgery recovery, dilated pupils
Bright sunlight on screen
Hearing
Deaf, hard of hearing
Ear infection
Loud airport, sleeping partner
Motor
Limb difference, paralysis
Broken arm, RSI flare
Holding a child, using phone on bus
Speech
Non-verbal
Laryngitis, dental surgery
Heavy accent in foreign country
Cognitive
Intellectual disability, ADHD
Concussion, medication side effects
Sleep deprivation, high stress
Language
Non-native speaker
Traveling abroad
Domain-specific jargon
Key insight: Designing captions for Deaf users also helps the person in a noisy airport, the non-native speaker, and the parent with a sleeping baby. One solution serves millions.
Universal Design Principles
The 7 Principles of Universal Design (developed at North Carolina State University):
1. Equitable Use
The design is useful to people with diverse abilities.
Provide the same means of use for all - identical when possible, equivalent when not
Avoid segregating any group of users
Make provisions for privacy, security, and safety equally available
Example: A building entrance with a ramp that everyone uses (not a separate "accessible entrance" around back).
Digital example:
html
<!-- Inequitable: separate "accessible version" link -->
<a href="/accessible-version">Click here for accessible version</a>
<!-- Equitable: one version that works for everyone -->
<main>
<video controls>
<source src="video.mp4" type="video/mp4">
<track kind="captions" src="captions.vtt" srclang="en" label="English">
<track kind="descriptions" src="descriptions.vtt" srclang="en" label="Audio descriptions">
</video>
<details>
<summary>Read transcript</summary>
<div class="transcript">...</div>
</details>
</main>
2. Flexibility in Use
The design accommodates a wide range of preferences and abilities.
Provide choice in methods of use
Support right- or left-handed access
Facilitate accuracy and precision
Provide adaptability to the user's pace
Digital example: Multiple ways to complete the same action:
html
<!-- Multiple input methods for the same task -->
<div class="file-upload">
<!-- Drag and drop (mouse users) -->
<div class="drop-zone" role="region" aria-label="Drop files here">
Drag files here
</div>
<!-- File picker (keyboard, screen reader, mobile users) -->
<label for="file-input" class="upload-button">
Or choose files
</label>
<input type="file" id="file-input" multiple>
<!-- Paste from clipboard (power users) -->
<p class="hint">You can also paste images from your clipboard (Ctrl+V)</p>
</div>
3. Simple and Intuitive Use
The design is easy to understand regardless of experience, knowledge, language, or concentration level.
Eliminate unnecessary complexity
Be consistent with user expectations
Accommodate a wide range of literacy and language skills
Arrange information consistent with its importance
Provide effective prompting and feedback
4. Perceptible Information
The design communicates necessary information effectively regardless of ambient conditions or sensory abilities.
Use different modes (visual, verbal, tactile) for essential information
Provide adequate contrast between information and its background
Maximize legibility of essential information
Differentiate elements so they can be described (make it easy to give instructions)
Digital example: Status communicated through multiple channels:
html
<!-- Color + icon + text: three channels for the same information -->
<div class="status status-error" role="alert">
<svg aria-hidden="true" class="icon-error"><!-- X icon --></svg>
<span class="status-label">Error:</span>
Payment declined. Please try a different card.
</div>
<style>
.status-error {
border-left: 4px solid #d32f2f;
background-color: #fde8e8;
color: #1a1a1a;
/* Never rely on color alone - the icon, label, and border
all communicate "error" independently */
}
</style>
5. Tolerance for Error
The design minimizes hazards and adverse consequences of accidental or unintended actions.
Arrange elements to minimize hazards and errors
Provide warnings of hazards and errors
Provide fail-safe features
Discourage unconscious action in tasks that require vigilance
6. Low Physical Effort
The design can be used efficiently and comfortably with minimum fatigue.
Appropriate size and space is provided for approach, reach, manipulation, and use regardless of body size, posture, or mobility.
Inclusive Personas
Building Inclusive Personas
Traditional personas often represent a narrow "average" user. Inclusive personas deliberately represent the edges.
Template for an inclusive persona:
markdown
## Persona: [Name]
**Demographics**: Age, location, occupation
**Abilities**: [Be specific - not "disabled" but "uses screen magnification at 200%"]
**Devices**: [What they actually use, including assistive technology]
**Context**: [Where and when they use the product]
**Connectivity**: [Speed, reliability, data caps]
**Motivation**: [What they are trying to accomplish]
**Frustrations**: [What currently blocks or slows them]
**Quote**: [A sentence that captures their perspective]
Example Inclusive Personas
Persona: Maria, 67
Recently retired teacher, moderate low vision, uses Windows magnification at 175%
Desktop computer with 24" monitor, broadband internet
Wants to manage finances online but finds small text and hover interactions difficult
"I should not need my grandson's help to pay my bills."
Persona: James, 32
Software developer with ADHD, uses multiple monitors
Fast connection, latest hardware, keyboard-centric workflow
Needs focused interfaces; distracting animations and notifications break his flow
"Every pop-up notification costs me 20 minutes of focus."
Persona: Aisha, 24
University student, Deaf since birth, fluent in sign language, English as second language
iPhone, 4G connection, uses VoiceOver occasionally for proofreading
Needs captions, visual indicators for audio events, plain English
"If your tutorial is a video without captions, it does not exist for me."
Persona: Carlos, 45
Construction foreman, uses phone one-handed on job sites
Android phone, cracked screen, dusty gloves, direct sunlight
Needs large touch targets, high contrast, offline capability
"I can't take off my gloves every time I need to check a delivery schedule."
Persona: Priya, 38
Mother of three, intermittent 3G connection in rural area
Needs fast load times, minimal data usage, works offline
"If the page doesn't load in 5 seconds, I give up."
Edge Case Identification
The Edge Case Matrix
For each feature, ask:
Dimension
Edge Cases to Consider
Input
No input, maximum length, special characters, RTL text, emoji, paste from PDF
Name
Single name, hyphenated, apostrophe, very long name, non-Latin characters
Screen size
320px wide, 4K ultrawide, zoomed to 400%, landscape phone
Connection
Offline, 2G, unstable (tunnel), high latency, metered data
Device
Old phone, screen reader, switch device, keyboard only, touch only
Content
Empty state, 1 item, 10,000 items, missing image, very long text
Language
RTL languages, German (long words), CJK characters, translations 2x longer
Identity
Non-binary gender options, chosen vs legal name, no fixed address
Time
Different time zones, DST transitions, international date formats
Payment
Prepaid, no credit card, different currencies, gift cards
Name Field Inclusivity
html
<!-- Exclusive: assumes Western naming convention -->
<label>First Name</label>
<input name="first_name" required>
<label>Last Name</label>
<input name="last_name" required>
<!-- Inclusive: single flexible field or optional structure -->
<label for="full-name">Full name</label>
<input id="full-name" name="full_name" autocomplete="name" required>
<p class="hint">Enter your name as you'd like us to use it</p>
<!-- If you must collect structured names -->
<label for="given-name">Given name(s)</label>
<input id="given-name" name="given_name" autocomplete="given-name">
<label for="family-name">Family name(s)</label>
<input id="family-name" name="family_name" autocomplete="family-name">
<p class="hint">Not everyone has both - fill in what applies to you</p>
Gender Inclusivity
html
<!-- Exclusive -->
<select name="gender" required>
<option value="male">Male</option>
<option value="female">Female</option>
</select>
<!-- Inclusive - only ask if truly necessary -->
<fieldset>
<legend>Gender (optional - helps us personalize your experience)</legend>
<label><input type="radio" name="gender" value="woman"> Woman</label>
<label><input type="radio" name="gender" value="man"> Man</label>
<label><input type="radio" name="gender" value="nonbinary"> Non-binary</label>
<label><input type="radio" name="gender" value="self-describe"> I prefer to self-describe:
<input type="text" name="gender_custom" aria-label="Gender self-description">
</label>
<label><input type="radio" name="gender" value="prefer-not"> Prefer not to say</label>
</fieldset>
Inclusive Design Review Checklist
Content and Language
☐To do:
Content is written at an appropriate reading level
☐To do:
Jargon and acronyms are defined on first use
☐To do:
Instructions use plain, direct language
☐To do:
Content is translatable (no text in images, string externalization)
☐To do:
RTL layout support is implemented or planned
☐To do:
No culturally specific idioms or metaphors that do not translate
Visual Design
☐To do:
Color is never the sole means of conveying information
☐To do:
Text contrast meets WCAG AA (4.5:1 normal, 3:1 large)
☐To do:
Non-text contrast meets 3:1 for UI components and graphics
☐To do:
Design works at 200% zoom without loss of content
☐To do:
Design works at 400% zoom with content reflow
☐To do:
Dark mode is supported or does not break in OS dark mode
☐To do:
Animations respect prefers-reduced-motion
Interaction Design
☐To do:
All functions available by keyboard
☐To do:
All functions available by touch (no hover-dependent features)
☐To do:
Touch targets are at least 44x44 CSS pixels
☐To do:
No interaction requires precise timing or dexterity
☐To do:
Drag operations have single-pointer alternatives
☐To do:
Forms use appropriate autocomplete attributes
☐To do:
Error messages are specific and actionable
Identity and Representation
☐To do:
Name fields accommodate diverse naming conventions
☐To do:
Gender fields are inclusive or omitted if not essential
☐To do:
Address fields work for international formats
☐To do:
Imagery represents diverse people authentically
☐To do:
No stereotypical representations of disability, race, gender, or age
☐To do:
Avatars and defaults do not assume demographics
Performance and Context
☐To do:
Core features work on slow connections (3G)
☐To do:
Page weight is under 1MB for primary views
☐To do:
Critical content works without JavaScript
☐To do:
Offline or poor-connection states are handled gracefully
☐To do:
Content works on screens as narrow as 320px
Technology
☐To do:
Semantic HTML is used throughout
☐To do:
ARIA is used only where HTML semantics are insufficient
☐To do:
All custom components follow ARIA Authoring Practices patterns
☐To do:
The page works in the 2 most recent versions of major browsers
☐To do:
Screen reader testing has been performed with at least 2 screen readers
Measuring Inclusivity
Quantitative Metrics
Task completion rate by user segment - Break analytics by device type, location, and (where ethically gathered) ability
Error rate by segment - Are certain groups hitting more errors?
Time on task by segment - Who takes much longer?
Abandonment rate by page - Where are people giving up?
Accessibility score over time - Track axe-core violations per sprint