UI 폴리시

잘 구성된 화면도 여전히 미완성으로 느껴질 수 있습니다. 17px만 어긋난 두 열의 필드, 390px 폰에서 88px 박스, 각 필드를 따라다니는 단위 단어, 엄지손가락으로 터치할 수 없는 링크 등이 그 예입니다. 사람들은 이런 것들을 즉시 느끼지만, 스크린샷을 검토하는 모델은 거의 보지 못합니다. 이 스킬은 먼저 측정하고, 두 번째로 판단하며, 측정이 통과했다고 말할 때만 결함이 수정되었다고 간주합니다.

입력

누락된 것만 물어보세요.

대상. URL, HTML 파일, 또는 렌더링되는 URL이 포함된 리포지토리의 컴포넌트. 렌더링할 방법이 필요합니다. 렌더링할 수 없으면 그렇게 말하고 루브릭만 사용하여 모든 측정 검사를 "측정되지 않음"으로 표시합니다.
범위 (선택 사항). 다듬을 페이지 부분의 CSS 선택자(예: form 또는 main). 기본값: main, 없으면 body.
참조 (선택 사항). 사용자가 더 낫다고 생각하는 화면(URL, 파일 또는 스크린샷). 이것도 측정하고 디자인 방향으로 사용하십시오. 브랜드, 콘텐츠 또는 주장은 절대 복사하지 마십시오.

워크플로

1. 현재 화면 측정

번들된 스크립트를 실행합니다(Node 및 Playwright with Chromium 필요; 프로젝트에 없으면 npm i -D playwright && npx playwright install chromium으로 설치):

node <skill-dir>/scripts/measure.cjs <file-or-url> --out ui-polish/before [--scope "<selector>"] [--primary "<selector>"] [--hide "<selector>,…"] [--profile form|content]

핸드폰(390×844) 및 데스크톱(1366×900)으로 렌더링하며(오류 발견 시 exit 1, 사용법 오류 시 2, 실행 실패 시 3), measure.json을 --out 디렉토리(현재 디렉토리 기준)에 쓰고, 뷰포트당 두 개의 스크린샷(<viewport>.png (첫 번째 화면) 및 <viewport>-scope.png (스크롤 아래 포함한 전체 범위))을 생성하며, 각 발견 사항을 선택자와 함께 출력합니다. 원인이 동일한 요소는 카운트와 예시 선택자가 포함된 하나의 발견 사항으로 처리되며, 핸드폰과 데스크톱에서 동일한 발견 사항은 한 번만 출력되고 viewports에 둘 다 포함됩니다(병합된 발견 사항을 뷰포트별로 필터링할 때는 viewport가 아닌 viewports 사용).
스크립트는 기본적으로 꺼져 있어 정적 레이아웃이 측정됩니다. JavaScript로만 렌더링되는 페이지에는 --js를 추가하십시오. --offline은 대상 페이지를 제외한 모든 네트워크 요청을 차단합니다(밀폐형). --assets-only는 원격 폰트, 스타일시트 및 이미지도 로드하도록 허용하며, 저장된 복사본이 폰트를 필요로 할 때 해당 호스트에 접속합니다.
--hide는 측정 및 캡처 전에 쿠키 배너나 채팅 런처와 같은 오버레이에 display: none을 설정하여 스크린샷을 가리거나 발견 사항을 추가하지 않도록 합니다. 일치하는 항목이 없는 --hide 선택자는 경고를 출력합니다.
--profile content는 기사 및 기타 긴 형식의 페이지용입니다. 폼 단계용 검사(type-scale, action-distance, action-below-fold, dead-space)를 건너뜁니다. 기본값은 form입니다.
한 번 실행에 여러 대상(measure.cjs <page1> <page2> … --out dir)은 각각 dir/<slug>/에 저장되며, dir/summary.json은 여러 페이지에서 반복되는 발견 사항을 페이지 목록과 함께 한 줄로 병합합니다. 공유 컴포넌트는 한 번만 수정하십시오. 페이지별 비교(--compare before/<slug>/measure.json after/<slug>/measure.json).
검사 및 임계값, 그리고 각각의 일반적인 수정 방법은 reference/checks.md에 있습니다. 오류는 실행을 실패하게 합니다. 경고는 수정 또는 명시된 사유가 필요합니다.
사유는 매 실행마다가 아니라 한 번만 명시하십시오. 현재 디렉토리(또는 --config <file>)에 있는 ui-polish.config.json은 허용된 결정을 나열합니다(예: { "ignore": [{ "check": "text-size", "selector": ".eyebrow", "reason": "브랜드 키커 레이블" }] }). 일치하는 발견 사항은 사유와 함께 accepted로 이동하며, 자체 섹션에 출력되고 종료 코드에 영향을 주지 않습니다. 소유자가 내린 결정만 기록하십시오. 숫자를 통과시키기 위해 결정을 추가하지 마십시오.

참조가 주어진 경우, 동일한 방식으로 ui-polish/reference에 측정하십시오.

2. 살펴보기

스크린샷(-scope.png는 전체 범위를 보여줌)을 열고 reference/rubric.md의 10개 항목을 모두 살펴보십시오. 항목당 한 행(및 항목 10의 하위 검사당 한 행)의 평가표를 작성하십시오: 통과, 실패 또는 해당 없음, 발견된 문제 및 수정 방법. 화면에 있는 것만 평가하십시오. 측정은 루브릭의 증거이지 대체물이 아닙니다. 측정된 발견 사항이 0개인 화면도 계층 구조, 레이블 및 단위, 그룹화 또는 신뢰성에서 실패할 수 있으며, 사람들이 가장 먼저 알아차리는 실패는 대개 이런 것입니다.

3. 수정 계획 세우기

측정된 모든 발견 사항과 실패한 각 루브릭 항목에 대한 수정 방법을, 해당 요소별로 그룹화하여 나열하십시오. 각 발견 사항을 개별적으로 패치하는 것보다 여러 발견 사항을 동시에 제거하는 구조적 수정(예: 2열 그리드에서 필드 위의 레이블은 정렬, 동일 너비, 필드 채움, 레이블 배치 및 접근 가능한 이름을 함께 해결)을 선호하십시오. 화면을 사용하는 사람에게 미치는 영향 순서로 정렬하십시오.

4. 소스에 수정 적용

실제 소스를 편집하십시오: 리포지토리의 컴포넌트와 스타일, 또는 HTML 파일. 규칙:

작업과 콘텐츠 유지. 동일한 질문, 동일한 입력 및 단위, 동일한 작업, 동일한 브랜드. 검사를 통과시키기 위해 기능을 제거하지 마십시오.
아무것도 발명하지 마십시오. 화면이 단어로 명시하지 않은 사실(단계 수, 시간, 가격, 임상, 법적 또는 개인정보 보호 주장)을 추가하지 마십시오. 코드에서 계산한 값(진행 표시줄의 aria-valuenow, CSS 너비, 경로 이름)도 명시된 것이 아닙니다. 역시 대괄호로 표시하십시오. 디자인에 그러한 문구가 필요하면 대괄호로 된 플레이스홀더(질문 [n] / [N], [~3]분, [질문하는 이유: …])를 사용하고 소유자가 작성할 수 있도록 목록을 작성하십시오.
기존 시스템 사용. 프로젝트의 토큰, 컴포넌트 및 간격 척도를 재사용하고, 맞는 값이 없을 때만 새 값을 추가하십시오.
작동 상태 유지. 모든 컨트롤은 이전에 수행한 작업을 계속 수행해야 하며(그리고 깨진 부분은 작동하도록), 키보드 포커스를 계속 볼 수 있어야 합니다.

5. 통과할 때까지 다시 측정

node <skill-dir>/scripts/measure.cjs <file-or-url> --out ui-polish/after [same options]
node <skill-dir>/scripts/measure.cjs --compare ui-polish/before/measure.json ui-polish/after/measure.json

비교 단계는 또한 소유자가 검토해야 할 모든 새 문구를 나열하며, 새 문구에 [대괄호] 밖에 숫자가 포함된 경우 invented-number로 실패합니다(예: "Step 2 of [5]": 2는 명시된 적이 없음).

오류가 없고, 모든 남은 경고가 수정되거나 명시된 사유가 있고, 그리고 모든 실패한 루브릭 항목이 수정되거나 명시된 사유가 있을 때까지 4-5단계를 최대 3회 반복하십시오. 매 라운드마다 새 스크린샷으로 루브릭을 다시 평가하십시오. 오류가 0개라고 끝난 것이 아닙니다. 36px 탭 대상 또는 후행 레이블과 같은 경고는 이 스킬이 존재하는 이유인 세부 사항입니다. 매 라운드마다 새 스크린샷을 여십시오. 검사가 통과했지만 화면이 더 안 좋아 보일 수 있으며 이는 퇴보로 간주합니다.

6. 보고

핸드폰 및 데스크톱에서의 전후 스크린샷.
비교 출력: 수정됨, 남음(사유 포함), 새로 생김, 및 허용됨(설정의 사유 포함).
전후 루브릭 평가표, 실패 상태로 남은 항목에 대한 이유 포함.
소유자가 채워야 할 모든 대괄호 플레이스홀더.
폴리시보다는 제품 결정이 필요한 모든 것(design-review 또는 소유자에게 전달).

주의사항

스크린샷은 기하학을 숨깁니다. 17px 열 오프셋이나 390px 화면의 88px 필드는 사람에게는 명백하지만 축소된 스크린샷에서는 보이지 않습니다. 기하학은 숫자를, 균형과 계층 구조는 눈을 신뢰하십시오.
후행 단위 단어는 일반적으로 열 정렬 불량의 원인입니다. "Feet"와 "Stones"는 너비가 다르므로 그 이후의 모든 것이 이동합니다. 필드 위에 레이블을 배치하십시오.
대용량 파일의 작은 편집은 계속 작습니다. 소스가 대용량 생성 파일인 경우, 속성별로 패치하는 대신 폼의 마크업과 스타일을 블록으로 편집하십시오. 그렇지 않으면 레이아웃이 변경되지 않습니다.
숫자가 통과할 때 멈추는 것이 전형적인 실패입니다. 기하학은 폴리시의 절반에 불과합니다. 나머지 절반은 루브릭입니다(실제 제목, 필드당 링크 대신 하나의 모드 전환, 민감한 질문에 대한 이유, 방향).
하나의 토큰, 많은 발견 사항. 모든 페이지에서 반복되는 작은 텍스트 또는 탭 대상 발견 사항은 일반적으로 하나의 디자인 시스템 토큰 또는 컴포넌트에서 비롯됩니다. 페이지별로 분류하는 대신 해당 위치에서 수정하거나 소유자의 결정을 ui-polish.config.json에 기록하십시오.
통과 검사가 목표가 아닙니다. 하나의 명확한 제목, 그룹화된 필드 및 가까운 기본 작업이 있는 집중된 화면이 목표입니다. 검사를 사용하여 도달했음을 증명하십시오.

만든이: aictrl.dev. 이 스킬은 워크플로를 가르칩니다. aictrl은 이를 운영화합니다 — 사용자의 백로그, 팀 표준 및 코드베이스 지식 그래프에 기반하여. 작동 방식 보기 →

UI 폴리시 (UI Polish)