언슬롭 디자인 (Unslop Design)

언슬롭 디자인 (Unslop Design)은(는) 무엇을 하나요?

세 부분으로 구성됩니다: 무엇을 고칠지(checklist.md, 각 수정 사항과 그 이유), 어떻게 조율할지(process.md, 검토자와 개발자가 병렬로 진행하는 라운드), 사례 및 출처(references.md: 이 스킬을 시작한 다섯 가지 전/후 사례와 Refactoring UI의 매핑). 모든 검토자가 작성하는 사양 카드는 spec-card.md에 있습니다. 플랫폼별 참고 사항(SwiftUI, Compose, 웹, 위젯, Watch, Car)은 platforms.md에 있습니다. 필요한 것만 읽고, 모두 읽을 필요는 없습니다.

원칙 (불가침)

1. 수정은 규칙이지, 임시방편이 아닙니다. 모든 변경은 뷰에 리터럴 값이 아닌 토큰 또는 컴포넌트(간격, 글꼴 크기, 두께, 색상 역할, 반경, 그림자, 버튼)로 제공됩니다. 토큰이 없으면 동일한 변경 사항 내에서 생성합니다. 값은 스케일 내에서 제거(elimination) 방식으로 선택하고(값과 그 이웃 두 개를 시도하고, 중간 값이 선택되거나 반복), 픽셀 단위로 조정하지 않습니다.
2. 색상보다 계층 구조가 먼저입니다. 화면은 그레이스케일에서 작동해야 합니다: 간격, 크기, 두께 및 대비가 역할을 하고, 색상은 그 다음에 의미를 부여하기 위해서만 사용됩니다. 회색조에서 무엇이 중요한지 명확하지 않다면, 색상이 해결해주지 않습니다.
3. 처음 읽는 것이 답입니다. 화면당 하나의 히어로 숫자(잔액, 가격, 오늘의 진행 상황)가 있고, 나머지는 모두 뒤로 물러섭니다. 히어로를 부풀리지 말고 경쟁 요소를 덜 강조함으로써 강조하십시오. 화면당 최대 하나의 어두운/히어로 표면만 허용하며, 시트나 모달에는 없습니다.
4. 색상은 한 가지를 말합니다. 액션이나 히어로 숫자에는 하나의 브랜드 악센트를 사용하고, 나머지는 의미 있는 역할(돈/성공, 상승/위험, 상태, 보상)을 가지며, 탐색용으로는 회색을 사용합니다. 장식용 색상 = 슬롭입니다. 색상은 단독으로 작동하지 않으며, 형태나 단어와 함께 사용됩니다.
5. 가정하지 않고 측정된 대비입니다. 실제 16진수 값을 실제 배경(라이트/다크)에 대해 계산한 WCAG AA(4.5:1 텍스트, 3:1 큰 텍스트 및 아이콘)를 준수합니다. 녹색/노란색 브랜드 색상 위의 흰색은 거의 항상 통과하지 못하며, 색상 배경 위의 회색 텍스트도 마찬가지입니다(동일한 색조의 음영을 선택하십시오).
6. 화면이 제공할 수 없는 것은 없습니다. 허구의 숫자, 데이터로 제시된 예측, 존재하지 않는 기능을 암시하는 것, 거짓말하는 빈 상태는 없어야 합니다. 실제로 출시할 수 있는 가장 작은 버전을 디자인하십시오.
7. 도메인에서 가져온 하나의 시그니처 제스처. 앱이 보여주는 것에서 탄생한 브랜드 디테일(가격 게시판의 마지막 자릿수가 작은 가격, 실행 중인 앱의 도트 매트릭스 숫자 등)로, 새로운 글꼴이나 효과가 아닙니다. 적용되지 않는 곳에서는 우아하게 저하됩니다. 그 외 모든 것은 네이티브를 따릅니다: 탭 바, 스위치, 시스템 시트와 싸우지 마십시오.
8. 플랫폼은 함께 출시됩니다. 프로젝트에 iOS와 Android(또는 앱과 웹)가 있다면, 변경 사항은 모든 언어에서 동일한 PR로 두 플랫폼에 모두 적용됩니다.
9. 사용자가 보는 것을 검증하십시오. 라이트/다크 모드 스크린샷, 가장 큰 텍스트 크기, 기본이 아닌 통화/언어, 실제 데이터(긴 이름, 빈 상태, 2,000개 항목)로 확인합니다. 사용자 환경에서 컴파일할 수 없는 것은 코드를 읽어 감사(audit)하고, PR에 그 사실을 명시합니다.

모든 에이전트 (Claude Code, Codex, Cursor, Copilot, Gemini…)

규칙은 모든 곳에서 동일합니다. "에이전트"라고 표시된 곳에서는 도구가 제공하는 기능을 사용하십시오: 서브에이전트가 있다면(Claude Code, Codex…), 각 개발자 영역에 git worktree를 사용합니다. 서브에이전트가 없다면 검토자를 하나씩 차례로 실행하고, 각각 고유한 브리핑을 제공하며, 심사 단계 전까지 출력물을 분리하여 유지합니다. "게시(publish)"라고 표시된 곳에서 Claude Code는 artifact를 게시하고, 다른 에이전트는 사용자가 열 수 있는 HTML 파일을 작성합니다. 코드베이스가 없는 채팅 앱에서는 전/후 제안 단계에서 멈춥니다.

작업 규약 (기본값)

• 검토자 = 시니어 제품 디자이너, 개발자 = 시니어 개발자 역할의 에이전트(사용자가 요청한 모델 사용). 오케스트레이터는 각 영역을 직접 빌드하지 않고, 공유 작업을 수행하고 통합 및 감사합니다.
• 모든 결정에는 명시적이고 실행 가능한 권장 사항이 함께 제공됩니다.
• 구현 전에 전/후를 게시하고 사용자의 "예"를 기다립니다.
• 각 라운드는 이전 라운드에서 출시된 내용과 수신된 모든 비디오/스크린샷(최신뿐만 아니라)을 다시 검토합니다.
• CI가 통과하면 병합이 허용됩니다: 컴파일 시 확인해야 할 사항(구체적인 위험) 목록과, Mac/시뮬레이터가 없는 경우 로컬 세션용 자체 포함 프롬프트를 함께 제시하며 마무리합니다.
• "다 끝났나요?" 질문에: 완료됨(PR 포함) · 사용자 대기 중 · 의도적으로 제외됨.
• 마지막 라운드 후 프로젝트의 디자인 시스템을 업데이트합니다.

간단한 흐름

1. 인벤토리: 비디오(process.md § 1), 화면 및 상태에서 프레임을 추출하고, 각 화면을 코드에서 찾습니다.
2. 시스템: 간격, 타이포그래피, 색상 및 위계 스케일을 확인(또는 생성)합니다(checklist.md § 시스템). 스케일이 없으면 검토자는 눈대중으로 판단합니다.
3. 그레이스케일 검토 + 병렬 검토자(3-4명, 영역당 한 명)가 checklist.md에 대해 한 번에 하나씩 수정 사항을 적용합니다.
4. 승리 제안: 전/후, 사양 카드 및 결정 목록이 포함된 하나의 HTML 페이지; 사용자가 선택합니다.
5. 각 영역의 개발자는 격리된 worktree에서 폐쇄된 브리핑을 가지고 작업합니다; 통합, 컴파일, 감사, PR, 리뷰 봇 응답, 통과 시 병합합니다.
6. 마지막으로: 새로운 내용으로 프로젝트의 디자인 시스템(문서 + 토큰 + 자체 스킬)을 업데이트합니다.

프로젝트에 이미 자체 디자인 스킬이 있는 경우

구체적인 토큰과 컴포넌트에는 해당 스킬을 사용하고, 이 스킬은 방법론과 일반 체크리스트를 제공합니다. 여기의 규칙이 문서화된 프로젝트 결정과 충돌하는 경우 프로젝트 규칙이 우선하며, 제안서에 그 점을 명시합니다.