Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计通过

design-everyday-things设计日常用品

Agent Skill

用于辅助界面设计、视觉规范、排版、配色、布局和交互体验优化。它适合让 Agent 根据产品场景整理页面结构、生成 UI 方案、检查视觉一致性或改进组件层级。使用时需要结合现有品牌、设计系统和用户任务,不应只堆装饰元素;涉及真实页面改动时,应通过截图或浏览器预览检查文本溢出、对齐和响应式表现。

总安装

30,264

周安装

1,333

GitHub Stars

779

下载量

10,608
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:design-everyday-things(设计日常用品)
来源仓库:https://github.com/wondelai/skills
仓库路径:skills/design-everyday-things
安装命令:
npx skills add https://github.com/wondelai/skills --skill design-everyday-things
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/wondelai/skills --skill design-everyday-things

简介

基于诺曼设计哲学构建直觉型产品体验,强调发现性与理解度。

  • 适合优化物理产品、软件系统及人机交互中的认知摩擦问题。
  • 核心在于平衡用户需求与系统能力,避免让用户承担设计缺陷成本。
  • 应将失败案例转化为学习机会,建立容错机制降低操作门槛。
  • design-everyday-things 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

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 works well, we take it for granted. When it fails, we blame ourselves — but the fault is almost always in the design.

The foundation: Design must bridge the gap between what people want to do and what the product allows them to do. The best designs are discoverable (you can figure out what to do) and understandable (you can figure out what happened).

Scoring

Goal: 10/10. When reviewing or creating designs, rate 0-10 based on discoverability, understandability, and error prevention. A 10/10 means users can figure out what to do without instructions, understand what happened, and recover from errors easily. Always provide current score and improvements to reach 10/10.

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.

Questions users ask:

  • What can I do here?
  • How do I do it?
  • Which control do I use?
  • How do I operate this control?

Bridging strategies:

  • Clear signifiers showing what's possible
  • Natural mappings between controls and outcomes
  • Constraints preventing wrong actions
  • Familiar conceptual models

Gulf of Evaluation

The gap between what the product did and what users understand happened.

Questions users ask:

  • What happened?
  • Did it work?
  • Is this what I wanted?
  • What state is the system in now?

Bridging strategies:

  • Immediate, visible feedback
  • Clear system state indicators
  • Meaningful error messages
  • Progress indicators

Design goal: Make both gulfs as narrow as possible. The ideal design requires zero bridging — action and understanding are 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?

Five components of discoverability:

  • Affordances
  • Signifiers
  • Constraints
  • Mappings
  • Feedback

(Each detailed below)

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

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

2. Affordances

Definition: The relationship between the properties of an object and the capabilities of the agent (user) that determine how the object could be used.

Key insight: Affordances exist whether or not they are perceived. A door affords pushing whether or not you know to push it. What matters is *perceived* affordance.

Types:

TypeDefinitionExample
Real affordancePhysical capability existsA button affords pressing
Perceived affordanceUser believes capability existsA raised area looks clickable
Hidden affordanceCapability exists but isn't obviousRight-click context menu
False affordanceAppears to afford action but doesn'tA decorative element that looks clickable
Anti-affordancePrevents actionA barrier that blocks movement

Digital applications:

ElementAffordanceHow to Signal
ButtonAffords clicking/tappingRaised, colored, shadow, hover state
Text fieldAffords text inputBorder, placeholder text, label
LinkAffords navigationColor, underline, cursor change
SliderAffords draggingHandle, track, visual range
Scroll areaAffords scrollingScroll bar, fade at edge, partial content

Common failures:

  • Flat design removes perceived affordances (is it a button or a label?)
  • Touch targets that are too small (fat finger problem)
  • No visual distinction between interactive and decorative elements

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

3. Signifiers

Definition: Signals that communicate where the action should take place.

Key insight: Affordances determine what's possible. Signifiers communicate where and how.

If affordances are what you CAN do, signifiers show you HOW to do it.

Types:

TypeDefinitionExample
Deliberate signifierDesigned to communicate"Push" label on door, placeholder text
Accidental signifierUnintentional but informativeWorn path in grass (people walk here)
Social signifierOther people's behaviorLine of people indicates entrance

Digital signifiers:

SignifierWhat It CommunicatesExample
Cursor changeThis is interactivePointer → hand on links
Hover stateThis responds to interactionButton color change on hover
Placeholder textWhat to type here"Enter your email..."
IconsFunction of the elementMagnifying glass = search
LabelsWhat this control does"Submit", "Cancel", "Next"
ColorStatus or categoryRed = error, green = success
PositionRelationship and hierarchyClose button in top-right corner

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

See: references/signifiers.md for signifier patterns and examples.

4. Mappings

Definition: The relationship between controls and their effects.

Natural mapping: When the spatial layout of controls matches the layout of the thing being controlled.

Examples:

Mapping QualityExampleWhy It Works/Fails
NaturalSteering wheel turns car directionDirect spatial correspondence
NaturalVolume slider (up = louder)Matches mental model
PoorLight switch panel (which switch = which light?)No spatial correspondence
PoorStovetop controls in a row (which knob = which burner?)Layout doesn't match

Digital mapping principles:

  • Controls should be near what they affect
  • Layout of controls should mirror layout of content
  • Direction of action should match expectation (scroll down = content moves up)
  • Grouping related controls together

Mapping techniques:

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 from 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.

Four types of constraints:

TypeMechanismExample
PhysicalShape/size prevents wrong actionUSB plug only fits one way (USB-C both ways)
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 last screw (process of elimination)

Digital constraints:

Constraint TypeImplementationExample
Input validationRestrict what can be enteredDate picker vs. free text
Disabled statesGray out unavailable options"Submit" disabled until form valid
Progressive disclosureShow options only when relevantPayment fields after selecting "Buy"
Forced sequenceSteps must be completed in orderWizard/stepper with locked steps
Undo/redoAllow reversalGmail "Undo send"

The power of constraints: Every constraint you add is one less error the user can make.

Design rule: Make it impossible to do the wrong thing, rather than punishing users for doing the wrong thing.

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.1 seconds for direct manipulation
  • Informative: Tells user what happened and current state
  • Appropriate: Not too much (annoying) or too little (confusing)
  • Non-intrusive: Doesn't block the user's workflow

Types of feedback:

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

Digital feedback patterns:

SituationFeedback NeededExample
Button clickVisual state changeButton depresses, color changes
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."
HoverInteractive element indicatorBackground color change, underline
DragObject follows cursorElement moves with mouse

Common failures:

  • No feedback at all (did my click register?)
  • Delayed feedback (makes system feel broken)
  • Unclear feedback (something happened but what?)
  • Too much feedback (every action triggers alert)

Response time guidelines:

  • 0.1s: Feels instantaneous (direct manipulation)
  • 1.0s: Noticeable delay (show cursor change)
  • 10s: Attention wanders (show progress bar)
  • 10s: User leaves (show percentage, allow background)

See: references/feedback.md for feedback design patterns.

7. Conceptual Models

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

Three models:

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

Goal: User's model should match the design model. The system image is the bridge.

When models match:

  • Users predict outcomes correctly
  • Users recover from errors easily
  • Users feel confident and in control

When models mismatch:

  • Users are confused and frustrated
  • Users blame themselves
  • Users give up or call support

Example: Thermostat

  • Design model: Set temperature, system maintains it
  • Common user model: Higher setting = faster heating (wrong!)
  • Result: Users crank thermostat to 90°F hoping for faster warmth

Building correct conceptual models:

  • Use familiar metaphors (desktop, folder, trash)
  • Make system state visible
  • Provide clear feedback
  • Use consistent behavior (same action = same result)
  • Progressive disclosure (simple model first, details available)

See: references/conceptual-models.md for model design frameworks.

Human Error

Norman's key insight: There is no such thing as "human error." There is only bad design.

When someone makes an error, 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 errorFamiliar action overrides intendedDrive to old office on autopilotInterruptions 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 fridgeProvide reminders, history

Design for Error

Error prevention:

  • Constraints that make errors impossible
  • Undo/redo for all actions
  • Confirmation for destructive actions
  • Sensible defaults
  • Forgiving input (accept variations)

Error recovery:

  • Clear error messages (what happened + how to fix)
  • Don't erase user's work on error
  • Allow partial saves
  • Easy reset to 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:

  • Stages 1-3 (execution): Support with clear signifiers, mappings, constraints
  • Stage 4 (action): Support with good affordances
  • Stages 5-7 (evaluation): Support with clear feedback, system state

Use as evaluation tool: Walk through each stage for any interaction. Where does the user get stuck?

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

Human-Centered Design (HCD) Process

Norman's design process:

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

1. Observation

  • Watch real users in real contexts
  • Don't ask what they want (they don't know)
  • Look for workarounds, frustrations, adaptations
  • Focus on activities, not individual tasks

2. Idea Generation

  • Generate many ideas (diverge before converge)
  • Don't criticize during ideation
  • Build on others' ideas
  • Defer judgment

3. Prototyping

  • Quick, cheap, disposable
  • Test concepts, not polish
  • Paper prototypes for early ideas
  • Interactive prototypes for validation

4. Testing

  • Test with real users (not designers)
  • 5 users reveal 85% of problems
  • Observe behavior, not just opinions
  • Iterate based on findings

Key principle: The design process is iterative. You'll go through multiple cycles, each time refining the design based on what you learn.

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

Reference Files

Further Reading

This skill is based on Don Norman's foundational design principles. For the complete framework:

About the Author

Don Norman, PhD is co-founder of the Nielsen Norman Group and director of The Design Lab at UC San Diego. He coined the term "user experience" while at Apple in the 1990s. *The Design of Everyday Things* (originally published in 1988 as "The Psychology of Everyday Things") is considered the most influential design book ever written and is required reading in virtually every design program worldwide. Norman has served as VP of Advanced Technology at Apple and has been a professor at Northwestern, UC San Diego, and KAIST (Korea).

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

38.23%
按下载量换算4,055

Claude

28.75%
按下载量换算3,050

Cursor

19.04%
按下载量换算2,020

Gemini CLI

8.95%
按下载量换算949

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills