UX 검토
목표
사용자와 의도한 결과 사이의 실질적인 장애물을 찾되, 단순한 스타일 선호도와의 차이에 그치지 않습니다. 증거에 기반하고, 우선순위가 명확하며, 실행 가능한 변경 사항을 제시합니다. 강점을 보존하고, 트레이드오프를 인정하며, 사용자 연구나 상호작용 테스트를 환각(hallucinate)하지 않습니다.
검토 모드
- 스크린샷 / 정적 디자인: 보이는 것만 검사합니다. 가능한 상호작용 위험은 가설로 표시하고, 컨트롤을 클릭하거나, 키보드 접근성을 확인하거나, 숨겨진 상태를 보았다고 주장하지 않습니다.
- HTML / 소스 코드: 가능하면 렌더링된 UI를 검토하고 관련 시맨틱, 스타일, 이벤트 처리를 검사합니다. 코드 검사만으로는 브라우저에서의 동작을 증명할 수 없습니다.
- 실제 작동 중인 애플리케이션: 브라우저 자동화 또는 컴퓨터 사용 도구를 사용할 수 있는 경우, 대표적인 작업을 수행하고 뷰포트별 증거를 캡처합니다. 도구가 존재한다고 가정하지 않습니다.
- 비교 / 회귀 분석: 이전/이후 상태에 대해 동일한 작업, 뷰포트, 증거 기준을 사용합니다. 실제 개선 사항과 새로운 회귀를 식별합니다.
- 수정 요청: 보고 후, 편집 도구를 사용할 수 있다면 범위를 좁혀 수리를 적용하고 재확인합니다. 사용자가 비평만 요청한 경우 파일을 변경하지 않습니다.
워크플로우
- 컨텍스트를 확립합니다. 대상 사용자, 작업, 화면 역할(개요/집중/수행/실행), 플랫폼, 제약 조건, 알려진 성공 지표를 식별합니다. 알 수 없는 경우 제품 조사를 만들어내지 말고 작업 가정을 명시합니다.
- 검사 가능한 증거를 수집합니다. 제공된 이미지, 목업, 애플리케이션 또는 코드를 검사합니다. 가능하고 요청에 비례한다면, 주요 흐름을 테스트하고, 메뉴를 열고, 키보드 컨트롤을 실행하고, 좁은/모바일 및 넓은 뷰포트를 확인합니다. browser-review.md를 참조하세요.
- 폴리시(polish)보다 사용자 결과를 먼저 감사합니다. 검사할 사항: 작업 명확성; 탐색 및 방향 찾기; 스캔 가능성 및 계층 구조; 수집 및 공개 패턴; 작업 피드백 및 복구; 콘텐츠 명확성 및 신뢰도; 반응형 동작; 접근성; 시각적 일관성. review-heuristics.md를 사용하세요. 모든 작업에 동일한 패턴이 최적이라고 가정하지 마십시오.
- 증거와 추론을 분리합니다. 발견 사항에 태그를 지정합니다: V 제공된 아티팩트에서 볼 수 있음, T 실제 작동하는 UI에서 직접 테스트함, C 코드에서 확인되었지만 실행되지 않음, H 그럴듯한 가설, U 알 수 없음/측정 필요. 정확히 관찰된 내용을 보고합니다. 모델 시뮬레이션을 사용자 연구라고 절대 부르지 마십시오.
- 우선순위를 지정합니다. 심각(완료 차단, 심각한 손해, 손실), 높음(일반적이거나 중요한 작업에서 큰 마찰), 중간(의미 있지만 차단하지 않는 비용), 낮음(사소한 개선)으로 할당합니다. 작업 영향, 노출 가능성, 복구 가능성, 증거 신뢰도를 고려하세요. 수치적 확실성을 조작하지 마십시오.
- 실행 가능한 수정 사항을 권장합니다. 각 실질적인 발견 사항에 대해 다음을 포함합니다: 위치, 증거, 중요한 이유, 구체적인 수정 사항, 확인 단계. 가치 있는 발견 사항 3-7개를 선호하고, 정당한 경우에만 더 많이 제시합니다. 좋은 선택은 명시적으로 보존하고, 실제 트레이드오프가 있는 경우 대안을 제시합니다.
- 루프를 종료합니다. 편집이 요청된 경우, 대상 변경을 수행하고, 영향을 받는 검사를 다시 실행하고, 남은 한계를 보고합니다. 연구가 필요한 경우, 선호도를 추측하기보다는 작고 현실적인 사용자 작업이나 실험을 제안합니다. reporting-and-evaluation.md를 참조하세요.
가드레일
- 비평을 요청하지 않은 리브랜드나 재구축으로 전환하지 마십시오. 구체적인 문제를 일으키지 않는 한 애플리케이션의 정체성과 작동 기능을 유지하십시오.
- 성기지 않은(흩어져 있는) 화면에 무차별적으로 점수를 부여하지 마십시오. 정보 밀도를 스캐닝, 비교, 의사 결정 요구 사항과 비교하여 평가하십시오.
- 시각적 취향을 사용성 결함으로 분류하지 마십시오. 주관적인 선호도는 별도로 표시하십시오.
- 정적 스크린샷만으로 메뉴가 깨졌다고 주장하지 마십시오. 어색한 외관과 테스트된 클리핑 또는 접근 불가능한 선택을 구분하십시오.
- 위치, 결과, 권장 변경 사항 없이 "간격 개선"과 같은 일반적인 발견 사항을 사용하지 마십시오.
- 측정 없이 디자인이 전환율이나 만족도를 증가시킬 것이라고 주장하지 마십시오.
- 발견적 평가, 자동화된 검사, 실제 사용자 관찰을 혼동하지 마십시오. 각각은 다른 종류의 증거를 제공합니다.
- 소스 데이터, 스크린샷 또는 코드가 불충분한 경우, 한계를 명시하고 다음으로 좁은 테스트를 제공하십시오.
기본 보고서
- 평결: 명시된 작업에 대한 적합성을 설명하는 한 문단; 잘 작동하는 부분을 포함합니다.
- 우선순위 발견 사항: 심각도 및 사용자 영향별로 정렬됨; 각 발견 사항은
위치 -> 증거 태그 -> 결과 -> 수정 -> 확인순서를 따릅니다. - 유지: 실수로 회귀(regress)시키지 말아야 할 중요한 강점.
- 알 수 없는 사항 / 테스트: 불확실한 제품 결정을 시각적으로 증명 가능한 문제와 분리합니다.
- 변경 사항이 있는 경우: 변경된 아티팩트, 실제 확인 사항, 확인되지 않은 상태.
간단한 스크린샷 비평의 경우 짧은 형식을 사용하십시오. 공식 템플릿이 유용한 답변을 가리지 않도록 하십시오.
참조 로딩
- review-heuristics.md: 조건부 검사 루브릭 및 일반적인 실패 패턴.
- browser-review.md: 브라우저 기반 작업 프로토콜, 뷰포트 및 접근성 스모크 테스트, 증거 규칙.
- reporting-and-evaluation.md: 심각도, 증거 레이블, 구체적인 예제, 개정 비교.