Source profileQuality 95/100

wondelai/skills/design-everyday-things/SKILL.md

design-everyday-things

Apply foundational design principles: affordances, signifiers, constraints, feedback, and conceptual models. Use when the user mentions "why is this confusing", "affordance", "error prevention", "discoverability", "human-centered design", "mental model", "mapping", "seven stages of action", "users keep making mistakes", "this is unintuitive", or "people cant figure out how to use it". Also trigger when reducing product complexity or feature creep. Covers the gulfs of execution and evaluation. Fo

Source repository stars
1,835
Declared platforms
0
Static risk flags
0
Last source update
2026-07-22
Source checked
2026-08-04

Decision brief

What it does—and where it fits

Foundational design principles for creating products that are intuitive, discoverable, and understandable. The "bible of UX" — applicable to physical products, software, and any human-designed system.

Best for

  • Use when the user mentions "why is this confusing", "affordance", "error prevention", "discoverability", "human-centered design", "mental model", "mapping", "seven stages of action", "users keep making mistakes", "this…

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/wondelai/skills --skill "design-everyday-things"
Safe inspection promptEditorial

Inspect the Agent Skill "design-everyday-things" from https://github.com/wondelai/skills/blob/dd37ee506ff558e939b3d421557987cced49b866/design-everyday-things/SKILL.md at commit dd37ee506ff558e939b3d421557987cced49b866. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Human-Centered Design (HCD) Process

    Two specifics that change how you run this loop: in Observation, don't ask users what they want (they don't know) — watch for workarounds and frustrations in real contexts. In Testing, use real users not designers — 5 reveal 85% of problems, so observe behavior over opinions and…

    Two specifics that change how you run this loop: in Observation, don't ask users what they want (they don't know) — watch for workarounds and frustrations in real contexts. In Testing, use real users not designers — 5 r…
  2. 02

    Core Principle

    Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible. When something fails, users blame themselves — but the fault is almost always in the design. Great design bridges the gap between wha…

    Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible. When something fails, users blame themselves — but the fault is almost al…
  3. 03

    Scoring

    Goal: 10/10. Score 2 points per satisfied row of the Quick Diagnostic (5 rows = discoverability, evaluation, error recovery, mapping, constraints). Bands: 9-10 = users act without instructions, understand every outcome, and recover from any error; 5-6 = one gulf or error path is…

    Goal: 10/10. Score 2 points per satisfied row of the Quick Diagnostic (5 rows = discoverability, evaluation, error recovery, mapping, constraints). Bands: 9-10 = users act without instructions, understand every outcome,…
  4. 04

    The Two Gulfs

    Every interaction with a product requires bridging two gulfs:

    Every interaction with a product requires bridging two gulfs:The gap between what users want to do and what the product lets them do. Users ask: What can I do here? Which control do I use?Bridge with: clear signifiers, natural mappings, constraints, familiar conceptual models.
  5. 05

    Gulf of Execution

    The gap between what users want to do and what the product lets them do. Users ask: What can I do here? Which control do I use?

    The gap between what users want to do and what the product lets them do. Users ask: What can I do here? Which control do I use?Bridge with: clear signifiers, natural mappings, constraints, familiar conceptual models.

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score95/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars1,835SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
wondelai/skills
Skill path
design-everyday-things/SKILL.md
Commit
dd37ee506ff558e939b3d421557987cced49b866
License
MIT
Collected
2026-08-04
Default branch
main
View the original SKILL.md

Design of Everyday Things Framework

Foundational design principles for creating products that are intuitive, discoverable, and understandable. The "bible of UX" — applicable to physical products, software, and any human-designed system.

Core Principle

Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible. When something fails, users blame themselves — but the fault is almost always in the design. Great design bridges the gap between what people want to do and what the product allows: it is discoverable (you can figure out what to do) and understandable (you can figure out what happened).

Scoring

Goal: 10/10. Score 2 points per satisfied row of the Quick Diagnostic (5 rows = discoverability, evaluation, error recovery, mapping, constraints). Bands: 9-10 = users act without instructions, understand every outcome, and recover from any error; 5-6 = one gulf or error path is broken; <=3 = users must consult a manual or routinely blame themselves. Report the current score and the diagnostic rows failing it.

The Two Gulfs

Every interaction with a product requires bridging two gulfs:

USER                                    PRODUCT
  │                                        │
  ├──── Gulf of Execution ────────────────→│
  │     "How do I do what I want?"         │
  │                                        │
  │←──── Gulf of Evaluation ──────────────┤
  │     "What happened? Did it work?"      │

Gulf of Execution

The gap between what users want to do and what the product lets them do. Users ask: What can I do here? Which control do I use?

Bridge with: clear signifiers, natural mappings, constraints, familiar conceptual models.

Gulf of Evaluation

The gap between what the product did and what users understand happened. Users ask: What happened? Did it work? What state is the system in?

Bridge with: immediate visible feedback, clear system-state indicators, meaningful error messages, progress indicators.

Design goal: Make both gulfs as narrow as possible — action and understanding should be immediate.

See: references/two-gulfs.md for gulf analysis exercises.

Seven Fundamental Design Principles

1. Discoverability

Definition: Can users figure out what actions are possible and how to perform them? Its five components — affordances, signifiers, constraints, mappings, feedback — are detailed below.

Test: Put a new user in front of your product. If they can't figure out what to do within 10 seconds, discoverability is broken.

Anti-pattern: "The user manual explains it." If users need a manual, the design failed.

2. Affordances

Definition: The relationship between an object's properties and a user's capabilities that determines how the object could be used.

Key insight: Affordances exist whether or not they are perceived — what matters for design is perceived affordance.

TypeDefinitionExample
RealPhysical capability existsA button affords pressing
PerceivedUser believes capability existsA raised area looks clickable
HiddenExists but isn't obviousRight-click context menu
FalseAppears to afford action but doesn'tDecorative element that looks clickable
Anti-affordancePrevents actionA barrier that blocks movement

Digital applications:

ElementAffordanceHow to Signal
ButtonClicking/tappingRaised, colored, shadow, hover state
Text fieldText inputBorder, placeholder text, label
Scroll areaScrollingScroll bar, fade at edge, partial content

Common failures: flat design erasing perceived affordances (button or label?), too-small touch targets, interactive and decorative elements that look identical.

See: references/affordances.md for affordance design patterns.

3. Signifiers

Definition: Signals that communicate where the action should take place. Affordances determine what you CAN do; signifiers show you WHERE and HOW.

TypeDefinitionExample
DeliberateDesigned to communicate"Push" label on door, placeholder text
AccidentalUnintentional but informativeWorn path in grass (people walk here)
SocialOther people's behaviorLine of people indicates entrance

Digital signifiers:

SignifierWhat It CommunicatesExample
Cursor change + hover stateThis is interactivePointer → hand on links; button color change
Icons + labelsFunction of the elementMagnifying glass = search; "Submit", "Cancel"
Color + positionStatus, category, hierarchyRed = error, green = success; close button top-right

Design rule: When in doubt, add a signifier — better to over-communicate than leave users guessing.

See: references/signifiers.md when deciding which signifier to add to an unclear control.

4. Mappings

Definition: The relationship between controls and their effects. Natural mapping means the spatial layout of controls matches the layout of what they control.

Mapping QualityExampleWhy It Works/Fails
NaturalVolume slider (up = louder)Matches mental model
PoorLight switch panelNo spatial correspondence to lights
PoorStovetop knobs in a rowLayout doesn't match burner positions

Digital principles: controls near what they affect, layout mirroring content, direction matching expectation (scroll down = content moves up), related controls grouped.

TechniqueHow It WorksExample
ProximityControl near targetEdit button next to content
SpatialLayout mirrors real worldMap controls match compass directions
CulturalFollows conventionsRed = stop/danger, green = go/safe
SequentialFollows natural orderSteps 1, 2, 3 left to right (or top to bottom)

See: references/mappings.md for mapping analysis exercises.

5. Constraints

Definition: Limiting the possible actions to prevent errors.

TypeMechanismExample
PhysicalShape/size prevents wrong actionUSB plug only fits one way
CulturalSocial norms guide behaviorRed means stop, green means go
SemanticMeaning restricts optionsA rearview mirror only makes sense facing backward
LogicalLogic limits choicesOnly one hole left for the last screw

Digital constraints:

ConstraintImplementationExample
Input validationRestrict what can be enteredDate picker vs. free text
Disabled statesGray out unavailable options"Submit" disabled until form valid
Forced sequence + undoSteps in order; allow reversalWizard with locked steps; Gmail "Undo send"

Design rule: Every constraint you add is one less error the user can make — make wrong actions impossible rather than punishing them.

See: references/constraints.md for constraint design patterns.

6. Feedback

Definition: Communicating the results of an action back to the user. Feedback must be immediate (within 0.1s for direct manipulation), informative, appropriately dosed, and non-intrusive.

TypeWhen to UseExample
VisualMost actionsButton press animation, color change, checkmark
AuditoryImportant events, confirmationsSuccess chime, error sound
HapticTouch devices, confirmationVibration on key press
ProgressLong operationsProgress bar, spinner, skeleton screen

Digital feedback patterns:

SituationFeedback NeededExample
Form submissionSuccess/error message"Saved!" toast or inline error
LoadingProgress indicatorSpinner, skeleton screen, percentage
ErrorWhat went wrong + how to fix"Invalid email. Please check format."

Response times: 0.1s feels instantaneous; 1s is a noticeable delay (change cursor); 10s loses attention (show progress bar); over 10s users leave (show percentage, allow backgrounding).

Common failures: no feedback (did my click register?), delayed feedback (feels broken), unclear feedback, alert overload.

See: references/feedback.md when an action gives no clear result and you need the right feedback type and timing.

7. Conceptual Models

Definition: The user's mental model of how a product works.

ModelHeld ByDescription
Design modelDesignerHow the designer thinks it works
User's modelUserHow the user thinks it works
System imageProductWhat the product actually communicates

Goal: The user's model should match the design model; the system image is the only bridge. Matching models let users predict outcomes and recover from errors; mismatches breed confusion, self-blame, and support calls.

Example (thermostat): design model — set a temperature, the system maintains it; common user model — higher setting heats faster (wrong), so users crank it to 90°F.

Build correct models with: familiar metaphors (desktop, trash), visible system state, clear feedback, consistent behavior, progressive disclosure.

See: references/conceptual-models.md when the user's model diverges from how the product works. For fully worked teardowns (door handles, thermostats, digital products), see references/case-studies.md.

Human Error

Norman's key insight: there is no such thing as "human error" — only bad design. When someone errs, look for the design flaw, not the person's flaw.

Types of Errors

Slips — correct intention, wrong action:

Slip TypeCauseExampleDesign Fix
Action slipWrong action on right targetClick "Delete" instead of "Edit"Separate destructive actions
Memory lapseForget step in sequenceForget attachment after writing "attached"Gmail's attachment reminder
Mode errorRight action, wrong modeType in caps lockShow mode state clearly
Capture errorHabit overrides intentionDrive to old office on autopilotInterrupt at decision points

Mistakes — wrong intention, executed correctly:

Mistake TypeCauseExampleDesign Fix
Rule-basedApply wrong ruleUse formula for wrong situationProvide context, confirm
Knowledge-basedIncomplete/wrong mental modelMisunderstand how system worksBetter conceptual model
Memory lapseForget goal or planForget why you opened the fridgeReminders, history

Design for Error

Prevent: constraints that make errors impossible, undo/redo everywhere, confirmation for destructive actions, sensible defaults, forgiving input. Recover: clear error messages, never erase the user's work, partial saves, easy reset to a known good state.

Error message checklist:

  • Says what went wrong (in human language)
  • Says how to fix it
  • Doesn't blame the user
  • Preserves user's work
  • Provides alternative path

See: references/human-error.md for error prevention patterns.

The Seven Stages of Action

Norman's model for how humans interact with products:

1. GOAL      → "I want to adjust the temperature"
2. PLAN      → "I'll use the thermostat"
3. SPECIFY   → "I'll press the up arrow"
4. PERFORM   → (presses button)
   ─── Gulf of Execution ───
5. PERCEIVE  → (sees display change)
6. INTERPRET → "The number went up"
7. COMPARE   → "Is this what I wanted?"
   ─── Gulf of Evaluation ───

Design implications: support stages 1-3 with signifiers, mappings, and constraints; stage 4 with good affordances; stages 5-7 with feedback and visible state. Walk any interaction through each stage to find where users get stuck.

See: references/seven-stages.md for stage-by-stage analysis.

Human-Centered Design (HCD) Process

Observation → Idea Generation → Prototyping → Testing → (iterate)

Two specifics that change how you run this loop: in Observation, don't ask users what they want (they don't know) — watch for workarounds and frustrations in real contexts. In Testing, use real users not designers — 5 reveal ~85% of problems, so observe behavior over opinions and iterate.

Common Mistakes

MistakeWhy It FailsFix
No signifiersUsers can't find featuresAdd visual cues for every interactive element
No feedbackUsers don't know if action workedRespond to every action within 0.1s
Blaming usersIgnores design flawsLook for design cause of every "user error"
Feature creepComplexity overwhelmsApply constraints, progressive disclosure
InconsistencyBreaks conceptual modelSame action = same result everywhere
Ignoring contextDesigned for ideal conditionsObserve real usage environments

Quick Diagnostic

Audit any design:

QuestionIf NoAction
Can users figure out what to do?Poor discoverabilityAdd signifiers, improve affordances
Do users understand what happened?Gulf of evaluation too wideAdd feedback, show system state
Can users recover from errors?No error toleranceAdd undo, confirmation, clear messages
Does the control layout match the output?Poor mappingReorganize controls to match spatial layout
Are impossible/irrelevant options hidden?Missing constraintsDisable, hide, or remove invalid options

Further Reading

For the complete framework:

About the Author

Don Norman, PhD is co-founder of the Nielsen Norman Group, director of The Design Lab at UC San Diego, and a former VP of Advanced Technology at Apple, where he coined the term "user experience." The Design of Everyday Things (1988, revised 2013) is widely considered the most influential design book ever written and is required reading in design programs worldwide.

Alternatives

Compare before choosing

Computed 10042,968

coreyhaines31/marketingskills

ab-testing

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

Computed 10042,968

coreyhaines31/marketingskills

churn-prevention

When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers o

Computed 100165

JasonColapietro/suede-creator-skills

suede-ab-testing

Suede-owned experimentation discipline for hypotheses, sample sizing, test duration, significance, and repeatable experiment programs. Use when comparing variants, deciding whether a result is reliable, or building an experiment backlog and cadence. NOT FOR: analytics instrumentation (use suede-analytics), post-click conversion diagnosis (use suede-site-alchemy), or writing the variant copy itself (use suede-copy).

Computed 1007

narrative-io/narrative-skills-marketplace

design-analysis

Translate a fuzzy analytical question into a rigorous investigation plan. Interrogates the ask, grounds the plan in the available data dictionary, applies analytical best practices, and produces a structured brief of query specifications for a downstream query-writing skill. Plans, does not write SQL. Use when: "why did X drop", "is there a relationship between A and B", "who are our highest-value customers", "what's driving the change in Y", "investigate this trend", "design an analysis for", "