ultrahand: review
전문 검사관처럼 UI 디자인을 리뷰하세요. 모든 플로우, 상호작용 및 컨트롤을 플랫폼 원칙, 닐슨의 10가지 휴리스틱, WCAG 2.2 AA 기준에 따라 점검한 후, 다른 크기에서도 디자인이 유효한지 확인하세요. 결과는 심각도별로 정렬된 문제 목록입니다. 각 문제는 요소, 위반 원칙 및 그 출처를 명시하고 구체적인 수정 사항을 제시합니다.
모든 검사는 references/checklist.md에 있으며, 각 검사는 references/sources.md를 인용합니다. 플랫폼 규칙에 대한 자세한 내용은 디자인 스킬의 자체 원칙 문서를 참조하세요:
mobile,
tablet 및
desktop.
테마가 있는 프로젝트의 경우 theme-review 스킬로 디자인을 확인하세요: 토큰 사용, 컴포넌트 재사용 및 화면 간 일관성은 이 스킬의 작업이 아닙니다.
1. 디자인을 확보하고 무엇을 보여줄 수 있는지 파악하세요
사용자가 제공할 수 있는 가장 풍부한 증거를 사용하세요. 어떤 종류의 증거를 가지고 있는지 명시하세요. 이는 확인할 수 있는 범위를 제한하기 때문입니다.
- ultrahand 캔버스 아티팩트 (claude.ai 아티팩트 링크): HTML을 읽으세요. 마크업, 레이블, 색상, 모든 화면 및 상태를 포함합니다. 브라우저 도구를 사용할 수 있다면 아티팩트를 여세요.
window.ultrahandCanvas(shared/canvas/의 캔버스 README 참조)를 통해 각 뷰를 설정하세요:usePreset(id),setSize(w, h),setScheme('dark'),setTextScale(2),setState('error'),navigate(id). 탭 타겟 표시를 켜고 그 결과(#uh-targets-result)를 읽으세요. 이는 플랫폼 최소 크기 미만인 타겟 수를 계산합니다. 시트나 메뉴를 연 후에는refresh()를 호출하여 개수에 포함되도록 하세요. 캔버스 README에는 툴바의 요소 ID가 나열되어 있습니다. 프로토타입의 스텁(실제 네트워크 없음, 온스크린 키보드 없음)은 문제 항목이 아닌 확인되지 않음에 포함됩니다. 하드웨어 키보드는 실제이므로 모든 플로우를 키보드로 구동하세요. - 로컬 캔버스 빌드 (
build.mjs의index.html) 또는 열 수 있는 모든 페이지: 아티팩트처럼 취급하고 입력 드라이버(4단계)와 함께 사용하세요. - 코드 (HTML, SwiftUI, Compose, Flutter 등): 레이블, 역할, 포커스 순서, 색상 및 중단점을 확인할 수 있지만, 실행할 수 없으면 모양은 확인할 수 없습니다.
- 스크린샷 또는 목업: 레이아웃, 계층 구조, 문구, 대략적인 대비 및 크기를 판단할 수 있습니다. 레이블, 포커스 순서 또는 동작은 확인할 수 없습니다. 해당 문제는 가능성 있음으로 표시하거나 확인되지 않음 아래에 나열하세요.
각 문제의 증거를 표시하세요: 확인됨 (코드에서 보거나 캔버스에서 측정) 또는 가능성 있음 (이미지에서 추론). 숨겨진 동작에 대한 추측을 사실로 제시하지 마세요.
2. 컨텍스트를 설정하세요
어떤 것을 판단하기 전에 다음을 기록하세요. 문제는 이에 비추어서만 의미가 있습니다.
- 플랫폼: iOS, iPadOS, Android, macOS, Windows 또는 웹. 캔버스(
size.platform), 코드 또는 시각적 스타일에서 읽으세요. 불명확하면 한 번 물어보세요. - 현재 크기: 가로 × 세로, 그리고 가로 크기 클래스: 컴팩트 < 600, 미디엄 600–839, 확장 840–1199, 라지 1200–1599, 엑스트라 라지 1600+. 세로 컴팩트 < 480, 미디엄 480–899, 확장 900+. 방향과 분할 여부를 기록하세요.
- 입력: 터치, 포인터, 키보드 또는 혼합. 태블릿이나 터치 노트북은 세 가지 모두 가질 수 있습니다.
- 사용자 및 주요 작업: 각 화면을 사용하는 사람과 그 화면의 목적. 추론할 수 없으면 물어보세요. 작업 없이 리뷰하면 의견 목록이 됩니다.
- 제품 또는 도구: 최종 사용자를 위한 디자인 또는 소유자를 위해 구축된 도구(캔버스 자체, 편집기, 뷰어). 도구는 모든 크기의 브라우저 창에서 사용되는 데스크톱 앱입니다. 데스크톱 규칙으로 리뷰하고 패스 8을 통과하세요. 해당 크롬은 패스 8에 나열된 패스 7 검사(창 크기, 브라우저 줌, 자체 테마)를 디자인의 프리셋이 아닌 패스 8 검사로 받고, 구성 패스는 다른 화면과 동일합니다.
창 크기 클래스 및 입력에 따라 플랫폼 규칙을 선택하세요. 기기 이름으로 선택하지 마세요: 컴팩트 터치 → 모바일 원칙; 미디엄 및 확장 터치, 또는 분할 → 태블릿; 포인터 및 키보드 창 → 데스크톱. 반응형 디자인은 해당 크기가 포함하는 모든 세트를 받습니다.
3. 디자인을 목록화하세요
모든 화면과 상태, 화면 간 모든 플로우, 각 화면의 섹션(툴바 및 해당 그룹, 창, 창 헤더, 양식 그룹, 카드, 목록, 막대) 및 각 섹션의 모든 대화형 컨트롤(버튼, 링크, 필드, 토글, 탭, 메뉴, 제스처, 드래그 타겟)을 나열하세요. 목록은 리뷰의 적용 범위입니다: 나열하지 않은 섹션이나 컨트롤은 확인하지 않은 것입니다.
세 가지 수준으로 리뷰하세요: 전체 화면, 각 섹션, 각 컴포넌트. 모든 컨트롤이 통과하는 화면이라도 여전히 복잡하고 정리되지 않아 혼란스러울 수 있습니다. 이는 그 자체로 문제이며 마무리 작업이 아닙니다.
4. 패스로 검사하세요
references/checklist.md의 패스를 순서대로 진행하세요. 디자인을 두 번 살펴보세요: 한 번은 학습하고, 한 번은 문제를 찾기 위해.
여러 크기에서 실제 입력으로 모든 컨트롤을 사용하세요. 마크업을 읽거나 el.click(), dispatchEvent 또는 세터를 호출하면 히트 테스트, 포커스, 기본 동작 및 스크롤 체인이 무시되므로 가려진 버튼이나 갇힌 휠이 여전히 정상으로 보입니다. 사람이 사용하는 방식으로 페이지를 사용하세요: node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs"의 신뢰할 수 있는 마우스, 휠, 키 및 터치 이벤트(README에 단계와 레시피가 있음) 또는 브라우저 도구의 실제 클릭과 키를 사용하세요. 스크립트는 뷰 설정 및 이후 상태 읽기에만 사용하세요.
- 세 가지 이상의 크기에서 수행하세요: 가장 큰 크기, 중간 크기 및 지원되는 가장 작은 크기(디자인의 경우 프리셋, 도구의 경우 1440×900, 1024×700, 640×480과 같은 브라우저 창).
- 각 크기에서 컨트롤을 나열한 다음(
controls), 각 컨트롤을 해당 종류에 맞게 사용하세요: 클릭 또는 탭, 입력, 드래그 및 Esc로 취소, 오른쪽 클릭, 키보드로 열고 닫기, 모든 스크롤러를 끝까지 휠 또는 스와이프. - 몇몇 기본 컨트롤은 헤드리스 상태에서 신뢰할 수 있는 입력으로 구동할 수 없습니다: 선택의 팝업, 파일 선택기, 색상 및 날짜 선택기. 드라이버의
choose단계로 선택 옵션을 선택하고 나머지는 확인되지 않음 아래에 나열하세요. - 각 결과를 읽으세요:
가려진컨트롤, 도달할 방법 없이 보이지 않거나 한 크기에서 누락된 컨트롤; 휠이 갇힌스크롤됨;body로 포커스 손실; 페이지 오류. 각각은 해당 크기의 문제입니다.
- 작업 워크스루: 각 플로우에 대해 모든 단계에서 네 가지 인지 워크스루 질문을 하세요.
- 구성: 전체 화면, 그다음 각 섹션을 구성 규칙(shared/composition/principles.md)에 따라 검사하세요. 가장 큰 크기와 가장 작은 크기에서 감사를 실행하고, 먼저 흐릿한 스크린샷을 읽은 후에 개별 컨트롤을 살펴보세요. 수정 버전을 리뷰할 때는 이전 버전과 비교하세요: 라운드에서 추가된 것은 무엇이며, 화면이 더 복잡해졌는가?
- 컨트롤별: 목록의 모든 컨트롤을 컨트롤 검사에 따라 검사하세요.
- 휴리스틱: 각 화면을 닐슨의 10가지 휴리스틱에 따라 검사하세요.
- 접근성: WCAG 2.2 AA. 대비를 계산하세요; 눈대중으로 하지 마세요.
- 플랫폼: 2단계의 플랫폼 및 크기 클래스에 대한 규칙.
- 크기 조정 및 변형: 모든 프리셋, 분할 너비, 320 리플로우, 200% 텍스트, 다크 모드, 각 데이터 상태, 터치 기기에서는 두 방향 및 키보드 올림(데스크톱 창은 회전하지 않음: 대신 최소, 최대 및 짧은 창을 확인).
- 도구: 소유자를 위해 구축된 도구의 경우, 모든 창 크기에서 작업이 보이고, 스테이지가 가장자리 너머로 패닝되고, 줌에 제한이 있으며, 단축키 및 드래그가 제대로 작동합니다.
문제를 발견하는 즉시 위치(화면 › 요소, 크기, 색상 구성표 및 상태 포함)와 함께 기록하세요. 여러 위치에서 나타나는 하나의 문제는 여러 위치를 가진 하나의 문제입니다.
5. 심각도 평가
닐슨의 0–4 척도를 사용하세요. 문제가 얼마나 많은 사용자에게 영향을 미치는지, 피해가 얼마나 심각한지, 사용자가 문제를 인지한 후에도 계속 피해를 주는지 고려하세요. 체크리스트의 심각도 가이드를 참조하세요.
| 평가 | 의미 |
|---|---|
| 4 재앙 | 작업 완료를 막거나 데이터를 손실시킴. 출시 전 수정 필수. |
| 3 주요 | 많은 사용자를 느리게 하거나 혼란스럽게 함, 또는 주요 플로우에서 WCAG AA 실패. 빠른 수정 필요. |
| 2 경미 | 일부 사용자를 느리게 하거나 명백한 해결 방법이 있음. |
| 1 미용 | 마무리 작업. 시간이 있으면 수정. |
0은 보고하지 마세요. WCAG AA 실패는 2 미만이 아닙니다.
6. 보고
한 단락 평결로 시작하세요: 플랫폼, 리뷰한 크기, 사용한 증거, 첫인상(흐릿한 화면이 보여주는 것, 화면이 체계적인지 복잡해 보이는지), 심각도별 개수, 최우선 문제. 체계적이지 않은 기본 표면을 버그와 동등하게 평가하세요: 이는 특정 경로뿐만 아니라 모든 사용을 느리게 합니다. 그런 다음 체크리스트의 템플릿을 사용하여 심각도가 높은 순서대로, 동일 심각도 내에서는 플로우 순서대로 문제를 나열하세요:
- ID 및 심각도, 예:
R3 · 3 주요 - 요소: 화면 › 섹션 › 요소(또는 구성 문제의 경우 화면 › 섹션 또는 전체 화면), 그리고 해당 문제가 나타나는 크기, 색상 구성표 또는 상태
- 증거: 확인됨 또는 가능성 있음
- 문제: 사용자에게 무엇이 잘못되는지, 한두 문장으로
- 원칙: 위반한 규칙과 출처 키(
WCAG 1.4.3,NNG-H4,tablet:AND-T2) - 수정: 값이 포함된 구체적인 변경 사항(
대비 개선이 아닌레이블을 #595959로 올려 7.0:1 달성)
잘 작동하는 부분(간략하게), 확인할 수 없었던 부분과 그 이유(스크린 리더 출력, 실제 기기, 모션), 그리고 리뷰어 한 명이 다른 사람이 발견하는 문제를 놓칠 수 있으므로 두 번째 리뷰어나 사용성 테스트를 수행할 가치가 있다는 메모로 마무리하세요.
보고서를 다른 사람에게 보내는 경우 아티팩트로 게시하겠다고 제안하세요. 일치하는 ultrahand 디자인 스킬로 수정 사항을 적용하겠다고 제안하세요.