MCP HubMCP Hub
스킬 목록으로 돌아가기

design-everyday-things

wondelai
업데이트됨 2 days ago
7 조회
1,112
121
1,112
GitHub에서 보기
디자인aidesign

정보

이 스킬은 'The Design of Everyday Things'의 핵심 UX 원칙을 적용하여 혼란스러운 인터페이스를 진단하고 수정합니다. 사용자가 발견성, 오류 또는 복잡성으로 어려움을 겪을 때, 어포던스, 시그니파이어, 피드백, 멘탈 모델을 분석해 도움을 줍니다. 오류 메시지를 개선하고 실수를 줄이며, 실행의 간격과 평가의 간격을 해소하는 데 활용하세요.

빠른 설치

Claude Code

추천
기본
npx skills add wondelai/skills -a claude-code
플러그인 명령대체
/plugin add https://github.com/wondelai/skills
Git 클론대체
git clone https://github.com/wondelai/skills.git ~/.claude/skills/design-everyday-things

Claude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요

문서

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

GitHub 저장소

wondelai/skills
경로: design-everyday-things
0
agent-skillsai-skillsclaude-codeclaude-code-marketplaceclaude-code-pluginclaude-code-skills

연관 스킬

executing-plans

디자인

executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.

스킬 보기

requesting-code-review

디자인

이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.

스킬 보기

connect-mcp-server

디자인

이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.

스킬 보기

web-cli-teleport

디자인

이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.

스킬 보기