designpaca/packages/skill/references/design-foundations.md

design foundations — 근거를 결정으로 바꾸는 법

교과서 요약집이 아니다. 각 원칙은 실제 과업에서 무엇을 확인할지 정하는 도구다. 출처의 상세 범위는 evidence ledger를 따른다.

1. 먼저 성공 과업을 한 문장으로 적는다

누가 / 어떤 맥락에서 / 무엇을 / 어떤 위험 없이 끝내야 하는가를 쓴다. 시각 방향은 그 뒤에 고른다. 첫 화면의 주장은 이름, 가치, 다음 행동을 모두 억지로 넣는 공식이 아니라 이 과업의 다음 결정을 충분히 설명하는지로 판정한다.

원칙	지지 주장	적용 조건	잘못된 일반화	구체 검증	예시 결정
관련성	불필요한 정보는 관련 정보의 가시성과 경쟁한다 [NNG-HEUR]	첫 선택과 오류 복구가 중요한 화면	요소 수가 적을수록 좋다	대표 과업에서 필요한 정보가 같은 화면에 있는지 본다	가입 전 가격 세부는 요약+상세 링크로 분리
위계	크기·명도·위치·여백은 함께 작동해 시선을 만든다 [NNG-VISUAL]	스캔이 필요한 랜딩·목록	h1:h2 비율 하나로 판정 가능	회색조 캡처를 짧게 보고 제목·주요 행동·본문의 읽는 순서를 기록한다	CTA만 색 대비, 섹션 제목은 공간 대비
근접성·유사성·공통 영역	가까움, 공통 외곽, 유사한 표식은 관계를 읽히게 할 수 있다 [GESTALT]	반복 모듈과 복잡한 정보	모든 영역이 12열 중앙 정렬이거나 카드여야 한다	카드·표·CTA의 묶음·분리·선택 상태를 회색조와 실제 과업에서 본다	사양과 가격은 한 group, 관련 도움말은 다음 group
정렬과 그리드	일관된 column·gutter·breakpoint는 제품 UI의 정렬 기준을 제공한다 [IBM-GRID]	여러 화면의 반복 표면	Carbon 격자나 특정 열 수가 보편 정답이다	콘텐츠 폭, 정렬선, 작은 폭의 재배치를 검증한다	읽는 surface와 비교 surface에 다른 폭 토큰을 둔다
직접 조작	멀수록 작을수록 조준이 느리고 오류가 늘 수 있다 [FITTS]	빈번한 포인터 행동	모든 버튼을 크게 만들면 해결된다	실제 hitbox, 거리, 인접 오탭을 관찰한다	아이콘만 누르게 하지 않고 라벨까지 클릭 가능하게
단서와 선택 설계	행동 단서는 지각 가능해야 하고, 선택 비용은 선택지 수만 아니라 구분·라벨·목표에 좌우된다 [NORMAN-SIGN, HICK, KRUG]	내비·필터·설정	7±2로 메뉴 수를 제한한다	사용자가 목표 항목을 찾는 시간·오류를 본다	9개 항목을 사용자 과업별 3개 묶음으로 재분류
기억보다 인지	화면의 상태·다음 행동·되돌림을 드러내면 기억 부담을 낮춘다 [NNG-HEUR, MILLER]	다단계·파괴적 행동	모든 것을 항상 보여야 한다	뒤로가기·오류·재진입에서 상태가 복구되는지 시험한다	업로드 후 파일명·교체·삭제를 같은 표면에 노출
인지 부하	과업에 필요 없는 기억·변환·탐색 단계를 줄이면 문제 해결 부담을 낮출 수 있다 [COGNITIVE-LOAD]	낯선 절차·설정·비교	모든 정보를 숨기거나 단계를 줄이면 더 쉽다	첫 사용자 과업의 오류·되돌림·완료 시간을 비교한다	설정 값을 군집화하고 선택 결과를 바로 옆에 보인다
간결함 ≠ 미니멀리즘	목적을 드러내는 것이 목표이지 요소를 지우는 것 자체가 목표가 아니다. 모든 것을 한 곳에 파묻으면 미니멀해 보여도 단순하지 않다 [SKILL-APPLE-DESIGN]	정보 밀도를 낮추는 리디자인 전반	요소 수를 줄이면 항상 더 쉬워진다	핵심 과업에 필요한 정보·컨트롤이 실제로 남아 위계로 정리됐는지 확인한다	옵션을 숨기지 않고 흔한 경로를 먼저, 고급 옵션은 한 단계 더 깊이 배치
구체적 라벨	직접적이고 구체적인 라벨이 안전하고 일반적인 라벨보다 예측 가능하다 — 내비는 내용물로 짓고("진행 상황", "보관함") "홈" 같은 우산 용어를 피한다 [SKILL-APPLE-DESIGN]	내비·탭·섹션 이름 짓기	라벨은 길고 설명적일수록 항상 낫다	사용자가 라벨만 보고 도착 화면을 예측할 수 있는지 시험한다	"홈" 대신 그 화면이 실제로 보여주는 것으로 탭 이름을 정함

구체적 라벨 규칙을 내비 구조에 적용하는 방법은 layout.md를 참조한다.

2. 접근성은 시각 스타일과 독립된 통과선이다

WCAG는 A·AA·AAA의 테스트 가능한 성공 기준이다. 제품의 목표 수준과 적용 법규·계약을 먼저 정하고, 장식적 선택이 그 기준을 넘어서는지 확인한다. AA는 일반적인 목표가 될 수 있지만, 이것만으로 모두에게 적합하다는 보증은 아니다 [WCAG-22].

• 텍스트 대비, 200% 확대, 320 CSS px reflow, 사용자 text-spacing, 포인터 target, 자동 움직임을 핵심 화면·상태별로 시험한다 [WCAG-READ, WCAG-TARGET, WCAG-MOTION].
• 모션 감소 선호에서는 움직임을 줄이되, 로딩·선택·오류 같은 상태 신호를 다른 방식으로 남긴다 [W3C-REDUCED].
• 스크린샷은 이 기준을 증명하지 못한다. 키보드·줌·사용자 스타일·보조기술 테스트를 별도 기록한다.

3. 성능 수치의 이름을 바르게 쓴다

Core Web Vitals 적합성은 실제 사용자의 field data에서 모바일·데스크톱별 75th percentile로 판단한다. 로컬 Lighthouse/DevTools/테스트 장비 수치는 개발 회귀를 잡는 lab proxy이며 field 판정이 아니다 [CWV, CWV-METHOD].

주장	필요한 증거
“개발 빌드가 이전보다 가벼워졌다”	같은 환경·시나리오의 bundle/전송량 또는 lab 결과
“CWV good”	RUM 또는 CrUX의 LCP·INP·CLS p75, 기간·트래픽 분리
“사용자가 더 빨리 끝낸다”	실제 과업 시간·성공률·오류/중단의 전후 비교
“이 디자인이 더 아름답다”	동일 브리프에서의 렌더 비교와 근거 있는 리뷰; 자동 점수로 단정하지 않음

4. 비교는 같은 조건에서 한다

브랜드 고유성, 시각 위계, 구도·리듬, 이미지 품질은 실제 렌더에서 비교한다. 평가자는 같은 브리프·폭·상태·콘텐츠에서 다음을 적는다: 무엇이 첫 번째로 읽히는가, 어떤 근거가 이 브랜드에만 맞는가, 반복이 정보 구조를 드러내는가, 이미지의 크롭·해상도·대체 텍스트가 목적을 지지하는가. 심미성 자동점수, 상 수상, 단일 클릭 수로 전환 인과를 주장하지 않는다 [AWWWARDS, WEBBY].

5. 필요할 때: 평가의 네 증거선을 분리한다

예쁘다는 평가와 실제 과업 결과가 엇갈리거나, 변경이 개선 효과를 냈다고 주장하려 할 때 이 절을 연다. 평가 종류가 답하는 질문은 다르다. 첫인상·취향, 실제 과업 행동, 접근성 적합성, 전문가의 시각 검토를 한 PASS로 합치지 않는다. 보기 좋은 표면이 사용성 평가를 좋게 느끼게 할 수 있으므로, 호감과 과업 결과도 따로 적는다 [NNG-AESTHETIC].

증거선	답하는 질문	최소 기록	다른 증거로 대체할 수 없는 것
첫인상·취향	무엇이 먼저 읽히고 어떤 인상을 주는가	같은 렌더 조건, 관찰, 해석	실제 과업 성공·접근성 적합성
실제 과업 행동	사람이 목표를 달성하며 어디에서 멈추거나 오류를 내는가	현실적인 중립 과업, 행동·발화·막힌 지점	표준 적합성·전문가 미감 판정
접근성 적합성	정한 WCAG 수준과 제품 계약을 충족하는가	기준, 상태, 키보드·확대·보조기술 결과	사용자 경험 전체
전문가 시각 검토	위계·타입·구도·이미지·리듬이 브리프와 맞는가	같은 조건의 전후 렌더, 관찰, 변경 근거	실제 사용자 연구

불확실하거나 영향이 큰 과업이면 실제 또는 예상 사용자가 현실적인 목표를 중립적 과제로 수행하게 하고, 답을 암시하지 않은 채 행동을 관찰한다 [GOV-TEST]. 실제 사용자 검증이 없으면 그 한계를 결과에 적고, 과업 효과를 확정적으로 주장하지 않는다. 사용자 평가는 표준 적합성 평가를 보완하며 대체하지 않는다 [W3C-USER-EVAL]. 일반적인 구현에 사용자 모집을 필수 게이트로 만들지 않는다. 에이전트 walkthrough는 정해진 시나리오의 회귀 점검일 뿐 실제 사용자 연구가 아니다.

수정은 관찰 → 원인 가설 → 한 가지 변경 → 같은 조건의 재비교로 남긴다. 필요하면 여러 구조적 대안을 탐색하고 작은 범위에서 시험해 버리거나 다듬는다는 Double Diamond의 프레임을 참고한다 [DC-DIAMOND]. 이 절차는 출처가 보장한 단일 방법이 아니라, 위 근거를 스킬 작업에 맞게 합성한 절차다. 고정된 관찰 시간·참여자 수·성공률 하나를 보편 통과선으로 쓰지 않는다.

6. 결정 기록 템플릿

- 출처 ID: WCAG-TARGET
- 지지 주장: 포인터 대상의 AA 최소 크기는 24×24 CSS px이다.
- 적용 조건: 모바일에서 빈번한 아이콘 행동.
- 잘못된 일반화: 모든 컨트롤에 44px가 법적 필수라는 말.
- 구체 검증: 390px에서 실제 클릭 영역과 인접 대상 간격을 측정한다.
- 예시 결정: 삭제 아이콘의 보이는 glyph는 16px, 클릭 영역은 28px로 둔다.

7. 조건부: 개인화와 AI 기능의 책임

개인화 — 조건부

언제: 웹앱 UI(대시보드·설정 화면처럼 반복해서 쓰는 도구)일 때만 연다. 랜딩 페이지·포트폴리오·마케팅 사이트에는 대체로 해당하지 않는다.

관찰 후보: 단일 레이아웃이 모든 사용자에게 맞지 않을 때는 컨트롤 재배치·안 쓰는 기능 숨기기 같은 개인화 여지를 설계 후보로 검토한다[SKILL-APPLE-DESIGN]. 개인화 자체를 기본값으로 강제하지 않는다 — 브리프나 사용자 조사가 요구할 때만 연다.

AI 기능이 있는 브리프의 책임

언제: 브리프에 AI 기반 기능(추천·생성·자동완성·챗봇 등)이 있을 때 연다.

프로젝트 계약: 오남용과 피해를 미리 예측한다 — 예를 들어 알레르기를 인지하는 레시피 기능은 유해한 재료를 제안하면 안 된다. 적절한 자리에 미리보기(실행 전에 결과를 확인하게 하기)·확인 단계·면책 조항을 두고, 위험이 가치를 넘는 기능은 잘라낸다[SKILL-APPLE-DESIGN]. AI 산출물을 실제 데이터처럼 보여줄 때의 진실 계약은 trustworthy-showcases.md §7("AI는 답이 아니라 검토 가능한 기록이다")을 따른다.