UX Playbook은(는) 무엇을 하나요?
비즈니스에 정확하고, 사용하기 쉬우며, 일관된 UI를 구축하세요. Mantine은 컴포넌트를 제공하고, 이 플레이북은 언제 어떤 컴포넌트를 사용할지, 화면에 어떤 상태가 필요한지, 결과를 어떻게 확인할지 알려줍니다. 작업에 필요한 페이지만 읽으세요.
우선순위
출처 간에 의견이 다를 경우, 더 높은 순위의 규칙이 우선합니다.
- 비즈니스 요구사항: 스펙, 티켓 또는 소유자의 지시. 절대 조용히 변경하지 마세요.
- 제품 자체 규칙:
AGENTS.md/CLAUDE.md, 제품의 UX 및 디자인 문서, 기존 컴포넌트. - 이 플레이북.
- Mantine 문서 및 기본값.
2와 3이 충돌하면 2를 따르세요. 2나 1이 잘못되었다고 생각되면 그래도 따르고 UX 제안을 제출하세요.
UI 작업 전에 제품의 UX 규칙을 찾아보세요(저장소 문서에서 "UX", "UI", "design", "panel" 검색). 없으면 제품 브리프 템플릿으로 초안을 작성하고, 계획이나 PR에 초안을 제안하세요. 모든 추정은 [가정] 으로 표시하세요.
티어 선택
| 티어 | 변경 사항 | 해야 할 일 |
|---|---|---|
| S | 기존 화면의 작은 변경: 필드, 버튼, 메시지, 열 | 건드리는 컴포넌트의 페이지를 읽습니다. 체크리스트를 실행합니다. 레이아웃이 변경되었다면 스크린샷을 찍습니다. |
| M | 새 화면, 대화상자 또는 폼, 또는 기존 것의 큰 변경 | 먼저 짧은 UX 명세를 작성합니다. 구축합니다. 시각적 검토를 수행합니다. 루브릭으로 자체 검토합니다. |
| L | 여러 화면을 가로지르는 새 흐름, 새 기능 영역, 또는 내비게이션 변경 | 2~3개의 옵션으로 연구 노트를 작성합니다. 안전한 옵션 A를 구축합니다. 그런 다음 각 화면을 티어 M으로 처리합니다. |
각 티어에 대한 세부 사항 및 산출물: 워크플로우.
페이지 찾기
| 결정하는 것 | 읽을 페이지 |
|---|---|
| 페이지 구조, 계층, 간격, 반응형 레이아웃 | decisions/layout |
| 버튼, 기본 vs 보조, 아이콘 버튼, 액션 메뉴 | decisions/actions |
| 모달 vs 드로어 vs 팝오버 vs 인라인, 툴팁 | decisions/overlays |
| 앱 내비게이션, 탭, 브레드크럼, 스테퍼, 페이지네이션, 링크 vs 버튼 | decisions/navigation |
| 테이블, 목록, 카드, 상태 레이블, 날짜, 긴 텍스트 | decisions/data-display |
| 토스트, 알림, 배너, 인라인 메시지 | decisions/feedback |
| 선택에 따른 입력: 체크박스, 스위치, 라디오, 분할 컨트롤, 셀렉트, 콤보박스, 칩 | decisions/selection |
| 폼, 레이블, 유효성 검사, 필수 필드 | patterns/forms |
| 저장 버튼, 자동 저장, 저장되지 않은 변경 사항 | patterns/saving |
| 아직 표시할 내용 없음, 결과 없음 | patterns/empty-states |
| 데이터 또는 작업 완료 대기 중 | patterns/loading |
| 고급 옵션, "더 보기", 요청 시 세부 정보 | patterns/progressive-disclosure |
| 기능 소개, 첫 실행, 힌트 | patterns/feature-onboarding |
| 백엔드 다운, 오프라인, 부분 실패, 권한 부족 | patterns/degraded-experiences |
| 삭제, 재설정, 취소, 덮어쓰기 | flows/destructive-actions |
| 레이블, 버튼 텍스트, 오류 텍스트, 빈 상태 텍스트 | writing |
| 키보드, 포커스, 레이블, 대비, ARIA | accessibility |
| Mantine API, 테마 토큰, 버전 조회 | mantine |
| 규칙의 이유 | principles |
항상
- 자체 컴포넌트를 만들기 전에 제품의 기존 컴포넌트와 Mantine을 사용하세요. 하나의 작업에 하나의 컴포넌트를 사용하세요.
- 모든 데이터 뷰에 로딩, 빈 상태, 오류 상태를 제공하세요. 모든 액션에 대기 상태와 결과를 제공하세요.
- 뷰당 하나의 기본 액션을 유지하세요. 보조 액션은 더 조용하게 배치하세요. 드문 액션은 메뉴에 넣으세요.
- 현재 사용할 수 없는 액션은 계속 표시하고 그 이유를 알려주세요. 사용자가 키보드와 터치로 접근할 수 있는 텍스트로 알려주고, 툴팁에만 의존하지 마세요.
disabled속성보다 비활성화된 모양(data-disabled)을 선호하고, 제출 버튼을 비활성화하지 마세요: actions. - 데이터를 파괴하는 작업은 확인을 받거나 실행 취소를 허용하세요. 오류 발생 시 사용자의 입력을 절대 잃지 마세요.
- 모든 입력에는 보이는 레이블이 있습니다. 의미가 색상만으로 전달되지 않습니다. 모든 것은 키보드로 접근 가능합니다.
- 전화 너비와 데스크톱 너비, 라이트 모드와 다크 모드에서 결과를 확인하세요: 시각적 검토.
- 여기의 예제는 리터럴 영어 문자열을 사용합니다. 제품의 i18n을 대신 사용하세요.
더 나아질 수 있다고 생각될 때
더 나은 흐름과 컴포넌트를 제안할 수 있으며, 그래야 합니다. 규칙은 안전한 기본값을 구축하고, 제안을 첨부하는 것입니다.
- 여기의 패턴을 사용하여 스펙이 요구하는 대로 구축하세요.
- 아이디어를 UX 제안으로 계획 또는 PR에 고정 형식으로 추가하세요.
- 스펙이 데이터를 잃거나, 비밀을 노출하거나, 키보드나 스크린 리더에 의존하는 사용자를 차단하거나, 스스로 모순될 때만 구축하기 전에 멈추고 물어보세요.
보고
모든 UI 작업을 PR 또는 보고서에 UX 노트 섹션으로 마무리하세요.
## UX 노트
- 티어: M — 새 "Mods" 탭
- 상태: 로딩 ✓ 빈 상태 ✓ 오류 ✓ 비활성화-이유-있음 ✓
- 스크린샷: 1280 라이트/다크, 390 라이트/다크 (첨부)
- 루브릭: 모두 통과; 해당 없음: 파괴적 작업 (없음)
- 가정: [가정] mods 목록이 짧음 (< 50), 따라서 페이지네이션 없음
- UX 제안: 1개 (아래 참조)