/grill-design
목표: 애플리케이션이 최종 사용자에게 어떻게 보이고 동작해야 하는지를 확립된 패턴과 실제 제품을 바탕으로 정의하고, 이를 영구적으로 기록합니다.
준비 (무음)
wiki/index.md,wiki/overview.md,wiki/ui-specs/의 관련 spec,schema/design-system.md(존재하는 경우)를 읽습니다.- 코드 내 기존 UI를 검사합니다 (컴포넌트 라이브러리, 토큰, Tailwind 설정, 유사한 화면).
- 패턴 카탈로그를 읽습니다.
- 해당 기능에 이전
/grill세션이 없고 비즈니스 규칙이 불확실한 경우, 먼저/grill을 실행할 것을 제안합니다.
진행 규칙
-
한 번에 하나의 질문과 함께 근거가 있는 추천을 제시합니다.
-
모든 디자인 질문에는 구체적인 제안이 다음 형식으로 포함됩니다:
**질문:** 사용자가 2,000개의 주문을 어떻게 탐색해야 하나요? | 옵션 | 패턴 | 참고 (복사할 대상) | 장점 | 단점 | |---|---|---|---|---| | A ⭐ | 데이터 테이블 + 패싯 필터 + 저장된 보기 | **Stripe 대시보드** (테이블 위 필터 칩), **Linear** (사이드바의 저장된 보기) | 확장성, 파워 유저 | 모바일에서 불리 | | B | 마스터-디테일 | **Gmail** (목록 + 상세 읽기 나란히) | 컨텍스트 유지 | 넓은 화면 필요 | | C | 카드 그리드 | **Airbnb** (사진이 있는 카드) | 시각적 | 비교 어려움 | **A를 추천합니다** 대상 사용자가 운영 직원이고 데스크톱을 사용하며 상태/값을 비교하기 때문입니다. -
참고 자료는 프로젝트 도메인과 실제로 관련된 앱이어야 합니다 (핀테크 → Nubank, Stripe, Mercury; 생산성 → Linear, Notion; 마켓플레이스 → Airbnb, Mercado Livre 등). 앱 이름뿐만 아니라 정확히 무엇을 복사할지 (구체적인 세부 사항) 말하세요.
-
에이전트에 웹 검색 기능이 있다면 예시(Mobbin, Page Flows, Dribbble)를 검색하여 풍부하게 할 수 있습니다.
-
가능하면 항상 추천 옵션의 ASCII 와이어프레임을 보여주세요.
-
기존 디자인 시스템을 존중하세요. 명시적으로만 변경을 제안하세요.
차원 (관련 항목을 이 순서대로 탐색)
| # | 차원 | 일반적인 질문 | 제안할 일반적인 패턴 |
|---|---|---|---|
| 1 | 사용자 및 컨텍스트 | 누구인가요? 사용 빈도는? 데스크톱/모바일? 기술 수준은? | — (나머지를 정의) |
| 2 | 여정 / 사용자 흐름 | 어디서 오고, 목표는 무엇이며, 어디로 가나요? 단계는? | 위저드, 허브-앤-스포크, 선형 흐름 |
| 3 | 정보 아키텍처 | 어떤 화면이 있나요? 계층 구조? 탐색 방법? | 사이드바, 탭, 하단 바, ⌘K, 브레드크럼 |
| 4 | 레이아웃 및 시각적 계층 | 초점은? 밀도? 그리드? 반응형? | 마스터-디테일, KPI 대시보드, 분할 보기 |
| 5 | 데이터 표시 | 목록, 테이블, 카드, 차트? 검색/필터/정렬? | 데이터 테이블, 칸반, 패싯, 저장된 보기 |
| 6 | 생성 및 편집 | 어떻게 생성/편집하나요? 유효성 검사? 저장? | 모달, 드로어, 인라인 편집, 자동 저장, 스테퍼 |
| 7 | 상태 | 로딩, 비어 있음, 오류, 성공, 부분, 권한 없음, 오프라인 | 스켈레톤, 교육적 빈 상태, 실행 취소 토스트, 낙관적 UI |
| 8 | 피드백 및 마이크로 인터랙션 | 확인, 전환, 호버, 단축키 | 토스트, 인라인 유효성 검사, 키보드 단축키 |
| 9 | 디자인 시스템 및 토큰 | 라이브러리(shadcn, Radix, MUI...)? 의미론적 색상, 타이포그래피, 간격, 다크 모드 | 의미론적 토큰, 4/8px 스케일 |
| 10 | 접근성 | 키보드, 포커스, 대비 AA, 스크린 리더, prefers-reduced-motion | 스킵 링크, 포커스 링, ARIA 패턴 |
| 11 | 콘텐츠 및 톤 | 마이크로카피, 언어, 말투, 오류 메시지 | — |
| 12 | 온보딩 및 활성화 | 처음 사용? 예시 데이터? | 체크리스트, 템플릿 갤러리, 샘플 데이터 |
종합
템플릿 ui-ux-spec.md를 채워서 spec을 제시합니다. 여기에는 다음이 포함됩니다:
- 채택된 패턴 표 (패턴 → 위치 → 참고 → 이유);
- 참고 자료 표 (앱 → 복사할 내용 → 피해야 할 내용);
- 주요 화면의 ASCII 와이어프레임;
- 컴포넌트별 상태 매트릭스;
- 디자인 시스템에 대해 제안된 새 토큰/규칙.
그리고 기록 표:
| 대상 | 파일 | 작업 |
|---|---|---|
| wiki | wiki/ui-specs/<화면-또는-흐름>.md | /wiki:add |
| wiki | wiki/concepts/<기능>.md (spec에 대한 링크) | /wiki:increment |
| schema | schema/design-system.md | /schema:add (처음) 또는 /schema:increment |
UI 구현 계획 (작업 / 티켓)
| 작업 | 수직 | 의존성 | 우선순위 | 작업 |
|---|---|---|---|---|
wiki/tasks/<화면-슬러그>.md | ui | - | medium | /ticket:new (wiki + 이슈) |
명시적 승인 (게이트)
"UI/UX spec, 디자인 시스템 기록, 작업 생성(+ GitHub 이슈)을 승인하시겠습니까? (예 / 조정)" — 명백한 승인 없이는 아무것도 기록하지 마십시오.
형식화 (승인 후)
- /wiki:add →
wiki/ui-specs/<슬러그>.md(type: ui-spec). - 관련 기능/엔티티 페이지에 /wiki:increment를 수행합니다.
- /schema:add 또는 /schema:increment →
schema/design-system.md(템플릿 design-system-rules.md 사용). - 계획된 각 UI 작업(컴포넌트, 화면, 상호 작용)에 대해 /ticket:new를 실행하고 라벨
vertical:ui(또는 기능의 수직)와status:planned를 추가합니다. wiki/log.md에 추가:## [YYYY-MM-DD] grill-design | <화면/흐름>와 함께 생성된 페이지 및 작업 목록.- 다음 단계 제안:
/implement <ui-작업>, 프로토타입, spec이 없는 인접 화면.