Communitygithub.com

markhougaard/ux-laws

UX 디자인 가이드 및 30가지 UX 법칙(LawsofUX.com) 기반의 엄격한 UI 리뷰를 제공합니다. 제품 또는 디자인 방향에 대한 조언, UI 디자인 및 프론트엔드 구현 가이드, 커밋 전 디자인, 프로토타입, 스크린샷 또는 UI diff 리뷰를 수행합니다. Fitts, Hick, Jakob, Miller, Tesler, Postel, Parkinson, Pareto, Occam, Doherty, Zeigarnik, Von Restorff, peak-end, serial position, goal-gradient, aesthetic-usability, choice overload, chunking, cognitive load, cognitive bias, working memory, mental models, flow, selective attention, paradox of the active user, Gestalt 법칙(근접성, 유사성, 공통 영역, 균일 연결성, 프래그난츠) 등이 언급될 때 사용하세요.

ux-laws란 무엇인가요?

이 스킬은 제품 디자인과 UI 개발 과정 전반에 걸쳐 UX 법칙을 체계적으로 적용할 수 있도록 설계된 AI 에이전트 도구입니다. 30가지 UX 법칙 각각에 대한 상세 참조 파일을 제공하며, Advise(조언), Build(구축), Review(리뷰) 세 가지 모드로 작동합니다. Advise 모드는 초기 개념 단계에서 핵심 법칙과 위험 요소를 식별하고, Build 모드는 개발 중인 구성 요소에 대한 구체적인 가이드라인(예: 대상 크기, 타이밍, 대비 비율)을 제공합니다. Review 모드는 커밋 전에 엄격한 증거 기반 검사를 수행하여 심각도(Blocker, Major, Minor)별로 문제점을 보고하고, 명확한 수정 방안과 통과/보류 여부를 결정합니다. 이 스킬은 파일을 읽을 수 있는 모든 AI 에이전트에서 작동하며, 명령어 기반 또는 참조 파일을 통한 자동 선택으로 사용됩니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/markhougaard/laws-of-ux/tree/HEAD/ux-laws

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

UX 법칙 — 색인 및 프로토콜

이 파일은 모드를 선택하고, 30가지 법칙 중 적용할 법칙을 선정하며, 법칙들을 함께 사용하는 방법과 보고 방법을 정의합니다. 각 법칙은 아래 표와 같이 references/ 디렉토리 아래에 각각의 고유 파일(fitts-law → references/fitts-law.md)로 존재합니다. 선택한 법칙의 파일만 열어 참조하세요.

사용자가 하나의 법칙을 직접 언급한 경우("Postel의 법칙으로 이 양식을 검토해줘"), 해당 참조 파일만 열고 사용자가 요청한 모드로 검토를 진행합니다. 리뷰는 여전히 5번 섹션의 규칙을 따릅니다.

0. 파일 및 환경

이 스킬은 파일을 읽을 수 있는 모든 에이전트에서 작동합니다. 특정 도구에 의존하지 않습니다.

  • 경로: 이 스킬의 모든 파일(참조 파일 포함)에서의 경로는 이 SKILL.md 파일이 있는 디렉토리를 기준으로 합니다. 따라서 references/fitts-law.md는 항상 <skill directory>/references/fitts-law.md를 의미합니다. (다른 참조 파일 내에서 이 경로가 사용되더라도 마찬가지입니다.)
  • 참조 파일을 열 수 없는 경우(예: 이 텍스트가 폴더 없이 프롬프트에 붙여넣어진 경우), 그 사실을 말하고 필요한 법칙 파일을 요청하세요. 메모리만으로 검사를 실행하지 마십시오: 검사 ID, 심각도 및 증거 유형은 해당 파일에만 정의되어 있습니다.
  • 증거는 검사 가능한 항목에 따라 달라집니다. 이미지, 스크린샷 및 목업을 볼 수 없다면 해당 항목은 사용자에게 static 증거로 간주되지 않습니다. 가지고 있는 텍스트나 코드를 검토하고 이를 범위 줄에 명시하세요. 아티팩트를 실행할 수 없다면, 사용자가 녹화본이나 측정값을 제공하지 않는 한 interactive 및 runtime 증거는 검토 범위에서 제외됩니다.

1. 모드 선택

모드사용 시기산출물
Advise (조언)목표, 브리프, 문제 설명, 로드맵 항목 또는 초기 개념만 존재할 때간결한 방향 제시 브리프: 여기서 가장 중요한 법칙, 예측되는 위험, 팀이 답해야 할 질문, 지금 내려야 할 결정
Build (구축)디자인 또는 구현이 진행 중이며 참고가 필요할 때검토 중인 컴포넌트나 화면에 맞춤화된 지침. 관련 법칙의 Mode 2에서 추출하며, 구체적인 값(있는 경우)을 포함
Review (리뷰)완성된 디자인, 프로토타입, 스크린샷 세트, URL 또는 코드 diff를 커밋하려고 할 때심각도, 증거, 수정 사항 및 판정을 포함한 엄격한 결과 보고서

요청에 모드가 명시되지 않은 경우 입력 내용을 통해 유추합니다. (목표 → Advise, 진행 중인 작업 → Build, 완성된 아티팩트 → Review). 여전히 불명확하면 질문을 하나 던지세요.

2. 법칙 선택

모든 작업에 대해 30가지 법칙을 모두 열지 마십시오. 상황에 따라 선택하고, 이후 관찰된 내용과 일치하는 트리거가 있는 법칙을 추가하세요.

모든 UI 리뷰의 기본 (항상 실행): fitts-law, jakobs-law, cognitive-load, law-of-proximity, law-of-similarity, selective-attention, cognitive-bias. 아티팩트가 인터랙티브한 경우에는 doherty-threshold를 추가합니다.

상황별:

상황열 법칙
양식, 데이터 입력, 가입postels-law, working-memory, chunking, law-of-proximity, parkinsons-law, goal-gradient-effect
내비게이션, 메뉴, 정보 구조hicks-law, serial-position-effect, mental-model, jakobs-law, chunking, pareto-principle
대시보드, 데이터 밀집형 및 전문가 도구cognitive-load, chunking, law-of-common-region, law-of-pragnanz, flow, pareto-principle
데이터 시각화 및 다이어그램law-of-pragnanz, law-of-uniform-connectedness, law-of-similarity, von-restorff-effect
온보딩, 첫 실행, 도움말paradox-of-the-active-user, goal-gradient-effect, zeigarnik-effect, cognitive-load, mental-model
가격, 요금제, 카탈로그, 체크아웃choice-overload, hicks-law, cognitive-bias, von-restorff-effect, serial-position-effect, peak-end-rule
알림, 경고, 상태selective-attention, von-restorff-effect, flow, zeigarnik-effect
모바일 및 터치fitts-law, law-of-proximity, serial-position-effect, doherty-threshold
성능, 로딩, 비동기 작업doherty-threshold, goal-gradient-effect, peak-end-rule, flow
리디자인 및 마이그레이션jakobs-law, mental-model, serial-position-effect, aesthetic-usability-effect
자동화, AI 및 스마트 기능teslers-law, mental-model, cognitive-bias, doherty-threshold
범위, 우선순위, 로드맵pareto-principle, occams-razor, teslers-law, hicks-law
비주얼 디자인 및 디자인 시스템 작업aesthetic-usability-effect, law-of-similarity, law-of-proximity, law-of-common-region, law-of-pragnanz, von-restorff-effect
오류, 실패 및 종료peak-end-rule, postels-law, selective-attention, mental-model

열린 각 법칙의 관련 법칙은 해당 법칙이 실제로 발견 사항이나 질문과 관련된 경우에만 따릅니다.

3. Advise (조언) 프로토콜

  1. 목표, 사용자 및 맥락을 두세 줄로 요약하세요. 사용자나 맥락을 알 수 없으면 그렇게 명시하세요. 이것이 첫 번째 위험 요소입니다.
  2. 표에서 3~6개의 법칙을 선택하세요. 6개 이상이면 조언의 효과가 희석됩니다.
  3. 각 법칙에 대해, 이 프로젝트에 대해 예측되는 한두 가지 위험과 팀이 답해야 할 질문을 제시하세요. 법칙의 Mode 1을 출처로 사용하되 구체적으로 만드세요.
  4. 지금 내려야 할 결정 사항(예산, 기본값, 규칙, 강조 규칙, 측정 기준)과 이를 담당해야 할 사람을 나열하세요.
  5. 신중한 선택이 필요한 법칙 간의 긴장 관계를 표시하세요 (6번 섹션 참조).

약 한 페이지 분량으로 유지하세요. 목표는 방향을 제시하는 것이지, 미리 디자인하는 것이 아닙니다.

4. Build (구축) 프로토콜

  1. 작업 중인 컴포넌트, 화면 또는 플로우를 식별하세요.
  2. 일치하는 법칙을 열고 해당 법칙의 Mode 2 목록을 참조로 사용하여 구체적인 값(대상 크기, 타이밍, 대비 비율, WCAG 기준)을 인용하세요.
  3. 지침이 상충될 경우 이를 말하고 이 경우에 대한 해결 방안 하나를 권장하세요.
  4. 구축 중에는 전체 리뷰를 실행하지 마세요. Review 수준의 문제가 발생할 가능성이 있는 Blocker인 경우에만 언급하세요.

5. Review (리뷰) 프로토콜 (엄격)

리뷰의 목적은 커밋 전에 문제를 방지하는 것입니다. 엄격성 규칙:

  • 증거가 없으면 통과가 아닙니다. 검사는 아티팩트에 긍정적인 증거가 있을 때만 통과합니다. 상태, 크기, 타이밍 또는 동작을 볼 수 없다면 절대 가정하지 마십시오.
  • 검증 불가능은 UNVERIFIED(미확인)을 의미하며, 통과(PASS)를 의미하지 않습니다. 필요한 항목(오류 상태, 측정값, 실제 데이터, 장치, 코드)을 명시하세요.
  • 범위는 명시되어야 하며, 암시되어서는 안 됩니다. 판정은 제공된 증거에만 적용됩니다. 제공되지 않은 증거 유형이 필요한 검사는 범위 밖(Out of scope)으로 나열됩니다. 따라서 스크린샷 리뷰가 전체 통과로 간주되어서는 안 됩니다.
  • 누그러뜨리지 마십시오. 칭찬을 덧붙이거나, "전반적으로 좋아 보인다"거나, 마감 기한이나 이미 투입된 노력을 이유로 심각도를 낮추지 마십시오.
  • 구체적으로 작성하세요. 모든 발견 사항은 위치(화면, 컴포넌트, 요소 또는 파일:줄), 관찰된 내용, 구체적인 수정 사항을 명시합니다.
  • 하나의 문제, 하나의 발견 사항. 여러 법칙이 동일한 문제를 지적하는 경우 한 번만 보고하고 모든 검사 ID를 나열한 후 가장 높은 심각도를 사용하세요.
  • 깨끗한 법칙을 명시적으로 보고하세요. 발견 사항 없이 적용된 법칙을 나열하여 적용 범위를 확인할 수 있게 하세요.

단계:

  1. 제공된 항목(화면, 상태, 중단점, 코드)과 누락된 항목을 목록화하고 **증거 범위(evidence scope)**를 설정합니다. (아래 증거 유형 중 어떤 것을 가지고 있는지)
  2. 기본 법칙과 상황별 법칙을 선택합니다.
  3. 선택된 각 법칙의 Mode 3 테이블에 있는 모든 검사를 실행합니다. 각 검사를 다음 중 하나로 분류합니다:
    • checked(검사 완료) - 통과했거나 발견 사항이 생성됨;
    • unverified(미확인) - 해당 증거 유형은 범위 내에 있지만, 필요한 상태, 요소 또는 측정값이 누락됨 (예: static 범위이지만 오류 상태 화면이 없음);
    • out of scope(범위 밖) - 필요한 증거 유형이 하나도 범위 내에 없음;
    • not applicable(해당 없음) - 아티팩트에 검사 대상이 없음 (예: 마우스 전용 데스크톱 도구에 대한 FIT-1). 이유를 몇 단어로 제시합니다.
  4. 중복을 병합하고 심각도를 할당하며 수정 사항을 작성합니다.
  5. 범위와 함께 판정을 내립니다.

증거 유형

Mode 3의 모든 검사에는 해당 검사를 해결할 수 있는 입력 유형을 명명하는 Evidence(증거) 열이 있습니다. 여러 개가 나열된 경우 그중 하나만 있으면 충분합니다.

유형설명일반적인 입력
static관련 화면 및 상태의 정적 이미지에서 볼 수 있는 것스크린샷, 정적 목업, 측정값이 있는 디자인 파일, 플로우 보드
interactive실제로 조작해야만 표시되는 것: 키보드, 포커스, 전환, 경험되는 타이밍, 작업 후 발생하는 상황클릭 가능한 프로토타입, 실행 중인 빌드, URL, 화면 녹화
code소스 또는 마크업에 있는 것: 시맨틱스, ARIA, autocomplete, 히트 영역, 토큰, 소스가 명확하게 정의하는 동작 (오류 시 핸들러가 하는 일, 입력이 유지되는지 여부, 포커스가 이동하는 위치)diff, 컴포넌트 소스, 렌더링된 DOM
runtime실제 하드웨어, 네트워크 및 데이터에 대한 측정값성능 추적, RUM 또는 실험실 수치
context아티팩트 외부의 사실: 사용 데이터, 리서치, 결정 기록, 비즈니스 규칙분석, 리서치 결과, PRD 또는 ADR, 팀의 진술

증거 유형이 범위 내에 있는 것으로 간주하려면 실제로 가지고 있어야 합니다. 코드가 존재한다는 말만 듣는 것으로는 code가 범위 내에 있는 것이 아닙니다.

심각도

심각도의미
Blocker핵심 작업을 방해하거나 오도함; 데이터 손실, 재정, 안전 또는 보안 위험 초래; WCAG 2.2 AA 기준 위반; 또는 기만적인 패턴. 커밋 전에 반드시 수정해야 함.
Major상당한 마찰, 오류 발생 가능성이 높은 디자인, 또는 규칙이나 디자인 시스템과 명백히 불일치. 커밋 전에 수정하거나, 명명된 소유자의 명시적인 승인과 후속 조치를 기록해야 함.
Minor다듬기 및 일관성. 해당 영역을 다음에 수정할 때 수정.

판정

일치하는 첫 번째 규칙을 적용하세요:

  1. Blocker가 하나라도 있음 → 커밋 금지(Do not commit).
  2. 범위 내 Blocker 검사가 UNVERIFIED임 → 증거 보류로 차단(Blocked pending evidence). 누락된 상태 또는 측정값을 명시하세요. 팀이 이미 제공한 증거와 함께 이를 제공했을 수 있습니다.
  3. Major가 하나라도 있음 → 각 Major가 수정되거나 명명된 소유자가 승인한 경우에만 커밋(Commit only with each Major fixed or accepted by a named owner).
  4. Minor만 있거나 없음 → 통과(Pass).

모든 판정에는 그 범위가 포함됩니다. 예: Pass (static scope). Blocker 검사 중 범위 밖(Out of scope)인 것이 있으면 판정 줄에 각각 필요한 증거 유형과 함께 나열하세요. 예: out of scope: JAK-1 (interactive), SA-2 (interactive), DOH-1 (interactive). 선택된 법칙의 Blocker 검사 중 범위 밖 또는 미확인 것이 없을 때만 판정은 수식어 없이("Pass") 사용될 수 있습니다. 범위 밖 검사는 판정을 변경하지 않습니다. 이는 팀에게 아직 검토되지 않은 부분과 릴리스 전에 더 많은 증거를 가지고 두 번째 검토가 필요한지 여부를 알려줍니다.

보고 템플릿

## UX 법칙 리뷰 — <아티팩트 이름>

검토 대상: <검토된 항목: 화면, 상태, 중단점, 파일>
증거 범위: <static | interactive | code | runtime | context — 실제로 제공된 것>
제공되지 않음: <누락된 상태 또는 증거>
적용된 법칙: <코드>
판정: <Do not commit | Blocked pending evidence | Commit with accepted Majors | Pass> (<범위> scope)
         범위 밖: <Blocker 검사 ID와 각각 필요한 증거 유형, 또는 "없음">

### Blocker
- [BLOCKER] FIT-1, JAK-1 · <위치> — <관찰 내용> → <수정 사항>

### Major
- [MAJOR] CL-2 · <위치> — <관찰 내용> → <수정 사항>

### Minor
- [MINOR] SIM-6 · <위치> — <관찰 내용> → <수정 사항>

### 미확인 (범위 내, 증거 누락)
- POS-2 · <확인할 수 없었던 항목> — <특정 상태 또는 측정값> 필요

### 범위 밖
- interactive: JAK-1, SA-2, DOH-1, …
- code: CH-3, PKL-3, …

### 해당 없음
- FIT-1 — <이유>

### 발견 사항 없이 적용됨
<코드>

6. 일반적인 긴장 관계

긴장 관계기본 해결 방안
Hick / Occam (옵션 줄이기) vs Pareto 긴 꼬리 및 전문가 요구프로그레시브 디스클로저를 통해 중요하지만 드문 기능을 찾을 수 있도록 유지; 사용량만으로 제거하지 마십시오.
Occam (제거) vs Tesler (줄일 수 없는 복잡성)우발적 복잡성은 제거; 본질적 복잡성은 시스템으로 이동시키되 가시성과 실행 취소 기능을 제공하십시오.
Jakob (규칙) vs 차별화핵심 컨트롤이 아닌 문제에 대해 혁신하십시오. 이탈은 명시되고 테스트된 이점이 있어야 합니다.
Von Restorff (강조) vs Similarity (일관성)뷰당 하나의 강조된 요소; 나머지는 모두 일관되게 유지하십시오.
Fitts (크고 편리한 대상) vs 우발적 활성화파괴적인 작업은 분리; 결과가 중대한 작업에는 실행 취소 또는 확인을 추가하십시오.
Flow (방해 금지) vs 안전 확인중대하고 되돌릴 수 없는 작업에 대해서만 방해하십시오.
Cognitive Load (적게 표시) vs Working Memory (맥락 표시)현재 단계에 필요한 맥락만 표시하고 나머지는 숨기십시오.
Postel (관대하게 수용) vs 정확성형식은 관대하게, 의미는 엄격하게; 모호한 중대한 값은 확인하십시오.
Goal-Gradient, Zeigarnik, Serial Position, Von Restorff를 레버로 사용 vs 사용자 관심사용자가 원하는 결과를 위해서만 사용하십시오; cognitive-bias를 참조하세요.

7. 모든 법칙

지각 및 주의

법칙코드용도
aesthetic-usability-effectAUE비주얼 폴리싱, 첫인상, 브랜드 표현, 사용성 테스트 해석, 제품의 외관과 작동 방식 간의 격차
law-of-common-regionCR카드, 패널, 섹션, 테두리, 배경 채우기, 테이블 행, 폼 그룹 및 항목이 함께 속함을 나타내는 모든 컨테이너
law-of-proximityPRX간격, 레이아웃 밀도, 레이블-필드 연결, 컨트롤 및 콘텐츠 그룹화, 간격 척도
law-of-pragnanzPRG아이콘, 일러스트레이션, 데이터 시각화, 레이아웃 실루엣, 로고 및 한눈에 이해되어야 하는 모든 시각적 요소
selective-attentionSA알림, 경고, 상태 변경, 배너, 온보딩 힌트, 시스템 메시지 및 사용자가 놓쳐서는 안 되는 정보 배치
law-of-similaritySIM시각적 일관성, 링크 및 버튼 스타일, 컴포넌트 변형, 상태 색상, 아이콘 패밀리 및 디자인 시스템 사용
von-restorff-effectVRE핵심 행동 유도 문구, 가격 강조, 오류 메시지, 주요 알림 및 다른 것과 구별되어야 하는 모든 단일 요소

기억 및 인지

법칙코드용도
choice-overloadCO카탈로그, 요금제, 설정 패널, 긴 목록 및 사용자가 결정을 내려야 하는 모든 곳
chunkingCH양식 단계, 입력 그룹화, 내비게이션 깊이, 데이터 테이블, 코드 편집기 출력, 진행 표시기 및 단계별 흐름
cognitive-biasCB가격 책정, 가입 플로우, 확인 대화상자, 기본값, 배치 및 선택 아키텍처
cognitive-loadCL복잡한 양식, 데이터 밀집형 화면, 마법사, 단계별 지침, 전문가 도구, 학습 및 검색 가능성
hicks-lawHIC메뉴, 도구 모음, 탭 바, 드롭다운, 명령 팔레트 및 사용자가 선택을 해야 하는 모든 곳
mental-modelMM내비게이션 패턴, 제스처, 용어, 아이콘 세트, 검색 동작, 워크플로우 및 개념 일관성
millers-lawMIL메뉴 항목, 탭, 추천, 스프린트 백로그, 알림 요약 및 수량 기반 결정
paradox-of-the-active-userPAU온보딩, 도움말 시스템, 기본값, 바로 가기, 설정 패널 및 생산성 기능
serial-position-effectSPE내비게이션 순서, 목록 레이아웃, 탭 순서, 드롭다운 순서, 진행률 표시줄 및 콘텐츠 우선순위
working-memoryWM양식, 데이터 입력, 다단계 흐름, 분할 주의 작업, 검색 필드, 가격, 오류 복구 및 컨텍스트 전환
zeigarnik-effectZEI온보딩 체크리스트, 진행 표시기, 저장 상태, 미완료 표시기 및 유지 및 완료율

동기 부여 및 행동

법칙코드용도
doherty-thresholdDOH버튼 반응, 전환, 스켈레톤 화면, 낙관적 업데이트, 로딩 인디케이터, 상태 업데이트 및 피드백 타이밍
flowFLW데이터 입력, 편집, 검색, 도구 작업, 게임, 창의적 작업 및 긴 작업 흐름
goal-gradient-effectGGE진행 표시기, 단계별 흐름, 포인트 적립, 온보딩 체크리스트 및 진행률 표시
law-of-effectLOE오류 메시지, 성공 확인, 보상, 칭찬, 애니메이션 및 결과 피드백
parkinsons-lawPKL자동 저장, 스마트 기본값, 공백 상태, 양식 완료 시간 및 데이터 입력 속도 향상
peak-end-rulePER오류 흐름, 온보딩 시퀀스, 체크아웃, 결제, 가입 취소 및 경험의 마지막 순간

상호 작용 및 제어

법칙코드용도
fitts-lawFIT버튼, 링크, 아이콘 터치 대상, 닫기 버튼, 드롭다운 트리거, 모바일 하단 시트 및 중대한 작업
jakobs-lawJAK내비게이션 패턴, 아이콘 의미, 제스처, 가격 표시, 검색 레이아웃, 로그인 위치 및 양식 동작
postels-lawPOS양식 입력, 데이터 가져오기, 주소, 전화번호, 날짜, 파일 업로드, 검색 및 오류 허용 오차
teslers-lawTES자동 완성, 자동화, 스마트 기본값, 매직 버튼, 구성 설정 및 복잡성 관리
pareto-principlePAR검색 결과, 대시보드 요약, 기능 우선순위, 설정, 보고서, 사용자 연구, 오류 로그 및 분석 데이터

게슈탈트 및 시각적 조직화

법칙코드용도
law-of-common-regionCR카드, 패널, 섹션, 테두리, 배경 채우기, 테이블 행, 폼 그룹
law-of-proximityPRX간격, 레이아웃 밀도, 레이블-필드 연결, 컨트롤 및 콘텐츠 그룹화, 간격 척도
law-of-pragnanzPRG아이콘, 일러스트레이션, 데이터 시각화, 레이아웃 실루엣, 로고
law-of-similaritySIM시각적 일관성, 링크 및 버튼 스타일, 컴포넌트 변형, 상태 색상, 아이콘 패밀리
law-of-uniform-connectednessUCN시각적 연결선, 흐름 다이어그램, 단계 표시기, 타임라인, 관계형 그래프

(참고: law-of-effect는 인지 편향 섹션에서 더 일반적으로 다루며, millers-law는 인지 섹션에 포함했습니다. 중복을 피하기 위해 위 테이블에서 doherty-threshold의 정식 명칭은 doherty-threshold입니다.)

관련 스킬