책노트: The Design of Everyday Things 1회차 - 사용자는 멍청하지 않다, 단서가 부족할 뿐이다

The Design of Everyday Things 1회차 - 사용자는 멍청하지 않다, 단서가 부족할 뿐이다

The Design of Everyday Things는 문손잡이와 스위치 이야기로 유명하지만, UX/UI를 다루는 개발자에게는 훨씬 실질적인 책이다. 이 책은 “사용자가 왜 헤매는가”를 심리학, 제품 구조, 피드백, 오류 회복, 조직 의사결정의 문제로 나누어 보게 한다.

이번 글의 질문은 이것이다. 사용자가 헤매는 순간, 우리는 무엇을 먼저 의심해야 하는가?

■ 이 노트의 사용법

이 글은 5회로 읽는 The Design of Everyday Things 시리즈의 1회차다. 범위는 개정판 서문, 1장 The Psychopathology of Everyday Things이다.

포착 -> 증류 -> 연결 -> 표현 4단계 깔때기로 UX 원칙을 개발자의 설계 판단으로 바꾼다. 핵심 원칙은 같다. 책 노트는 창고, 인사이트 카드는 화폐.

L0 · 서지 & 진입

• 한 문장 핵심: 사용성 문제의 상당수는 사용자의 능력 부족이 아니라, 인터페이스가 해야 할 일을 드러내지 못한 결과다.
• 이 책을 든 이유 / 기대한 질문: UX/UI 개발을 “디자인 전달받기”가 아니라 제품의 행동 문법을 구현하는 일로 보기 위해 읽는다.
• 읽기 전 가설: 처음에는 UX를 화면 배치와 스타일의 문제로 보기 쉽다. 이 회차는 UX를 “사용자가 다음 행동을 예측할 수 있게 하는 단서 설계”로 다시 정의하게 만든다.
• 저자 한 줄 컨텍스트: Don Norman은 인지과학, 인간-컴퓨터 상호작용, 사용자 중심 설계 분야를 대중적 언어로 연결한 연구자이자 설계 사상가다.
• 이번 회차 범위: 개정판 서문, 1장 The Psychopathology of Everyday Things
• 관련 도서 / 계보: A Philosophy of Software Design · The Pragmatic Programmer · A Theory of Fun for Game Design · Design System

L1 · 포착함

“ 짧은 핵심어 · #ux

“discoverability”

• 왜 표시했나: 보이지 않으면 없는 기능과 다르지 않다. ^q01
• 개발자 반응: 숨겨진 제스처와 묵시적 규칙은 개발자에게는 우아해 보여도 사용자에게는 막힌 문이다.

“ 짧은 핵심어 · #ux

“affordance”

• 왜 표시했나: 무엇을 할 수 있는지 몸이 먼저 짐작하게 하는 성질이다. ^q02
• 개발자 반응: 클릭 가능한 것, 드래그 가능한 것, 입력 가능한 것은 말보다 먼저 형태로 보여야 한다.

“ 짧은 핵심어 · #ux

“signifier”

• 왜 표시했나: 가능한 행동을 알려주는 표식이다. ^q03
• 개발자 반응: 디지털 UI에서는 버튼 모양, 라벨, 커서 변화, 비활성 상태, 마이크로카피가 모두 시그니파이어다.

■ 저작권 경계

이 공개 노트는 책의 장문 문장을 재현하지 않는다. 장 제목과 짧은 핵심어만 단서로 삼고, 내용은 UX/UI 개발자의 실무 해석과 적용 중심으로 재구성한다.

L2 · 챕터 지도

단위	내가 붙인 이름	핵심 주장	개발자 적용
1장	일상 사물의 병리학	사용자가 실패하는 장면을 통해 설계의 책임을 묻는다	실패를 사용자 탓으로 돌리기 전에 단서가 충분했는지 확인한다
핵심 개념	어포던스와 시그니파이어	가능한 행동과 그 행동을 알려주는 표식을 구분한다	컴포넌트는 기능뿐 아니라 행동의 힌트도 제공해야 한다
개념모형	사용자의 머릿속 모델	사람은 화면을 보고 시스템이 어떻게 움직이는지 추정한다	UI는 내부 구현이 아니라 사용자가 이해할 수 있는 모델을 보여줘야 한다
피드백	행동 이후의 반응	시스템이 지금 무엇을 했는지 알려주지 않으면 불안이 생긴다	로딩, 저장, 오류, 완료 상태를 명확히 드러낸다

이번 회차 논증 한 단락:

개발자가 UX/UI를 다룰 때 가장 쉽게 빠지는 함정은 “기능은 있는데 사용자가 못 찾는다”를 사소한 문제로 보는 것이다. 그러나 Norman의 관점에서 그 순간은 핵심 설계 실패다. 기능이 존재한다는 사실과 사용자가 그 기능을 발견할 수 있다는 사실은 전혀 다르다. 프론트엔드 개발로 옮기면 질문은 더 날카로워진다. 버튼은 정말 버튼처럼 보이는가. 비활성화된 이유는 설명되는가. 저장 중인지, 실패했는지, 성공했는지 사용자가 알 수 있는가. 메뉴 안에 숨긴 기능은 사용자의 현재 과업 흐름에서 발견될 수 있는가. 이 회차는 이런 질문을 “디자인 감각”이 아니라 “인터페이스의 책임”으로 바꾼다.

L3 · 인사이트 카드 색인

• The Design of Everyday Things - I1.1 UX 버그는 사용자 행동 로그가 아니라 단서 부족 로그다 — 사용자가 같은 지점에서 반복적으로 멈추면, 그것은 교육 부족보다 시그니파이어 부족일 가능성이 크다.
• The Design of Everyday Things - I1.2 좋은 컴포넌트는 기능과 행동 힌트를 함께 캡슐화한다 — 컴포넌트 API는 색과 크기만 받는 것이 아니라, 상태·금지·위험·다음 행동을 표현할 수 있어야 한다.
• The Design of Everyday Things - I1.3 디자인 시스템은 브랜드 규칙이 아니라 행동 문법이다 — 토큰과 컴포넌트는 예쁜 통일감보다 사용자가 “이것은 이렇게 쓰는 것”이라고 배울 수 있는 일관성을 제공해야 한다.

L4 · 생산 보드

■ 출력 파이프라인

• 블로그 초안: 1회차를 UX/UI 개발자 관점으로 정리
• 코드 리뷰 질문: 사용자가 헤매는 순간, 우리는 무엇을 먼저 의심해야 하는가?
• 디자인 시스템 카드: The Design of Everyday Things - I1.1 UX 버그는 사용자 행동 로그가 아니라 단서 부족 로그다
• 적용 실험: 최근 만든 화면 하나에 이 회차의 기준을 적용해 보기

바로 적용할 체크리스트

• 새 컴포넌트를 만들 때 가능한 행동, 행동 단서, 상태 피드백, 오류 회복을 PR 체크리스트에 넣는다.
• 아이콘 단독 버튼은 tooltip, aria-label, hover/focus 상태를 기본 계약으로 둔다.
• 사용자 행동 로그에서 클릭 실패·되돌아가기·반복 입력이 많은 지점을 “나쁜 사용자”가 아니라 “약한 단서”로 본다.

L5 · 연결 & 복습

• 다른 책/아이디어와의 연결: 이 회차는 A Philosophy of Software Design의 인지 부하 관점과 이어진다. 차이는 코드 내부 복잡성보다 사용자의 행동 복잡성을 다룬다는 점이다.
• 미해결 질문:
  • 우리 제품에서 사용자가 가장 자주 “멈추는” 화면은 어디인가?
  • 그 문제는 교육, 문서, CS로 해결할 일인가, 아니면 화면의 단서와 피드백을 고칠 일인가?
  • 디자인 시스템에 이 회차의 원칙을 어떤 컴포넌트 계약으로 넣을 수 있을까?
• 복습 일정: 1주 □ / 1개월 □ / 3개월 □
• 한 문장 최종 정리: 좋은 UI는 사용자를 똑똑하게 만드는 것이 아니라, 사용자가 이미 가진 직관을 낭비하지 않게 만든다.

다음 회차

• 이전: 5회차
• 다음: 2회차
• 책장으로 돌아가기: /book