UI declutter

UI declutter은(는) 무엇을 하나요?

인터페이스를 편집하여 모든 단어와 장식이 그것을 사용하는 사람을 위해 존재하도록 만듭니다. 생성된 화면은 스스로를 설명하는 경향이 있습니다: 제목 위의 레이블, 그 아래의 문장, 버튼 옆의 힌트. 각각의 추가는 무해해 보이지만, 함께 쌓이면 사용자가 찾아온 세 단어를 묻어버립니다.

목표는 사용자에게 도움이 되는 화면입니다. 생성된 것처럼 보이지 않기 위한 화면이 아닙니다. 규칙과 사용자의 필요가 충돌할 때 그 차이가 중요합니다: 사용자의 필요가 우선이며, 보고서에 그렇게 명시하세요.

대상: 사용자가 지정한 파일, 폴더 또는 컴포넌트. 사용자가 지정하지 않은 경우, 이 대화에서 변경된 인터페이스 파일을 대상으로 합니다. 해당 파일이 없으면 질문하세요.

범위: 텍스트, 액션, 상태, 허구 콘텐츠, 장식, 차트. 시각적 표면(규칙 X1~X4)은 사용자가 요청하거나 --surface 플래그를 사용할 때만 포함됩니다.

1단계: 이 화면에 있는 사람이 누구인지 말하기

문자열 하나를 읽기 전에, 한 줄을 작성하세요:

누구: 임무 중 Esc를 누른 플레이어. 하는 중: 다시 돌아갈지, 설정을 변경할지, 재시작할지 결정 중.

이 한 줄이 모든 것을 판단하는 기준입니다. 이것 없이 아래 규칙을 적용하면 패턴 매칭이 되어, 불필요한 내용과 함께 비밀번호 요구 사항까지 잘라낼 수 있습니다. 가격 페이지의 첫 방문자는 관리 테이블의 일일 사용자보다 더 많은 단어가 필요합니다. 게임은 세금 신고서가 가질 수 없는 분위기 있는 텍스트를 가질 수 있습니다.

코드에서 사용자가 누구인지 알 수 없다면, 제품과 상태로부터 추론하여 그 추론을 명시하세요. 두 가지 가능한 해석이 다른 편집으로 이어질 경우에만 질문하세요.

2단계: 테스트

보이는 각 텍스트와 각 장식 요소에 대해 질문하세요:

이것이 없으면, 그 사용자가 망설이거나, 실수하거나, 다음에 일어날 일에 놀라게 될까요?

• 아니요 → 잘라내세요.
• 아니요, 하지만 어딘가에는 누군가 필요로 합니다 → 옮기세요. 개발자를 위한 사실은 코드 주석에 넣으세요. 소수의 사용자가 찾는 사실은 툴팁이나 문서에 넣으세요. 보조 기술만 필요한 이름은 aria-label에 넣으세요.
• 예, 하지만 잘못 표현되었습니다 → 코드, 콘텐츠 또는 대화에서 찾을 수 있는 사실만 사용하여 다시 작성하세요.
• 예 → 유지하고 건드리지 마세요.

다음에 나오는 규칙들은 생성된 화면이 이 테스트를 통과하지 못하는 일반적인 방식입니다. 후보를 빠르게 찾는 데 도움이 됩니다. 화면이 규칙에 명명되지 않은 방식으로 테스트에 실패하면, 테스트는 여전히 적용됩니다. 규칙이 테스트를 통과하는 무언가를 지적하면, 그것을 유지하세요.

완전한 문장을 받을 자격이 있는 텍스트

다음은 거의 항상 테스트를 통과합니다. 레이블로 줄이지 말고, 잘라내지 마세요:

• 사용자가 충족해야 하는 제약 조건: 비밀번호 규칙, 허용되는 파일 형식 및 크기, 날짜 및 숫자 형식, 문자 제한.
• 결과: 파괴적이거나 되돌릴 수 없는 작업이 제거하는 것, 결제가 청구하는 금액과 시기, 권한이 부여하는 것, 공유되면 누가 볼 수 있는지.
• 오류: 무엇이 잘못되었고 다음에 무엇을 해야 하는지.
• 빈 상태: 여기에 속하는 것과 첫 번째 항목을 추가하는 방법.
• 동의, 법률 및 규제 텍스트. 문구를 절대 편집하지 마세요. 잘못된 것 같으면 보고하세요.
• 사용자가 드물게 수행하고 되돌릴 수 없는 작업에 대한 지침.

규칙

ID는 안정적입니다. 보고서에서 인용하세요.

텍스트

• C1. 눈썹 레이블. 제목 위의 작은 대문자 또는 자간이 넓은 텍스트 ("FEATURES", "HOW IT WORKS", "PAUSED" 위의 "OPERATION ON HOLD"). 제목이 이미 섹션을 나타내므로 눈썹 레이블을 잘라내세요. 눈썹 레이블이 더 나은 문장(게임의 분위기 텍스트, 제품의 자체 용어)이라면, 그것을 제목으로 승격시키고 일반적인 제목은 잘라내세요. 둘 중 하나만 남기고, 둘 다 남기지 마세요.
• C2. 장식용 번호 매기기. "01 02 03", "01 // 특징", "§" 및 "//" 접두사. 체크아웃 단계나 설치 가이드처럼 순서가 실제로 있고 사용자가 그 순서를 따르는 경우가 아니라면 잘라내세요.
• C3. 부제목 반사. 모든 제목 아래에 문장, 모든 메뉴 항목 아래에 설명("설정: 설정 업데이트"). 제목이 알려주지 않는 사실을 진술하는 경우에만 하나를 유지하세요.
• C4. 서술. 요소가 시각적으로 무엇인지 또는 무엇을 하는지 설명하는 도움말 텍스트 및 캡션("시작하려면 아래 버튼을 클릭하세요", "이 카드는 최근 활동을 보여줍니다"). 잘라내세요.
• C5. 구현 세부 정보 누출. 화면이 내부적으로 어떻게 작동하는지에 대한 텍스트 또는 프롬프트의 요구 사항이 텍스트로 렌더링된 것: "재개가 마우스를 다시 잡습니다", "(실시간 업데이트)", "(AI 기반)", "데이터가 5분 동안 캐시됩니다". 사용자가 이에 따라 행동하지 않습니다. 코드 주석으로 옮기거나 잘라내세요.
• C6. 상태 문자열. "·" 또는 "|"로 연결된 사실 ("12개 항목 · 2분 전 업데이트 · 동기화됨 · v2.1"). 사용자가 행동하는 사실을 유지하세요. 다른 사실은 필요한 곳에 두거나 잘라내세요.
• C7. 중복 단서. 플레이스홀더, 아이콘, 버튼 텍스트 또는 섹션 제목을 반복하는 레이블. 하나만 유지하세요. 양식 필드의 경우, 보이는 레이블을 유지하세요: 플레이스홀더는 입력 시 사라지며 접근 가능한 이름이 아닙니다.
• C8. 슬로건. "원. 큰. 것.", "다르게 만들어졌습니다.", "더 빠르게 배송하세요. 덜 생각하세요." 출처가 사실을 제공하는 경우, 대상을 지칭하고 그것이 하는 일을 말하는 한 문장으로 다시 작성하세요. 그렇지 않으면 소유자에게 플래그를 지정하세요.
• C9. 일반적인 섹션 제목. "왜 우리를 선택해야 하나요", "필요한 모든 것", "당신과 같은 팀을 위해 만들어졌습니다". 어떤 제품의 페이지에도 있을 수 있는 제목은 이 제품에 대해 아무것도 말하지 않습니다. 섹션 내용에 맞게 이름을 바꾸거나, 내용이 제목 없이도 성립하면 제목을 잘라내세요.
• C10. 힌트 과부하. 이미 텍스트 레이블이 있는 컨트롤의 툴팁, 모든 액션의 키보드 단축키 칩, "팁:" 및 "프로 팁" 콜아웃, 평범한 화면의 코치 마크. 컨트롤이 모호한 경우(아이콘 전용 버튼) 또는 단축키가 주요 사용 방식인 경우에만 힌트를 유지하세요.

액션

• A1. 모호한 액션 레이블. "시작하기", "더 알아보기", "제출", "계속", "확인", "여기를 클릭하세요". 버튼은 눌렀을 때 발생하는 일을 말해야 합니다: 동사, 그리고 동사만으로 모호할 때 목적어("계정 만들기", "CSV 내보내기", "초대 보내기"). 단계별 흐름 내에서는 "계속"과 "다음"이 괜찮습니다.
• A2. 하나의 액션, 여러 이름. 같은 작업에 대해 한 화면에서는 "삭제", 다음 화면에서는 "제거", 메뉴에서는 "휴지통", 또는 "로그인" 옆에 "로그인". 프로젝트에서 가장 많이 사용하는 용어를 선택하여 대상 전체에 적용하세요. 두 용어가 다른 작업을 명명하는 경우(목록에서 제거 대 영구 삭제), 둘 다 남겨두세요.
• A3. 확인 대화 상자. "확인"과 "취소"가 있는 "확실합니까?". 제목은 액션과 그 대상을 명명하고("프로젝트 3개를 삭제하시겠습니까?"), 본문은 결과가 있다면 그것을 진술하며("이 작업은 14개의 작업도 제거합니다. 실행 취소할 수 없습니다."), 확인 버튼은 동사를 반복합니다("프로젝트 삭제"). 사소하게 취소할 수 있는 액션의 확인은 그 자체로 잡음입니다: 소유자에게 플래그를 지정하세요.

상태

로딩, 성공, 빈 상태 및 오류 텍스트는 아무도 화면을 검토할 때 그 상태를 보지 않기 때문에 잡음이 모이는 곳입니다. 편집하기 전에 references/states.md를 읽으세요: 각 상태에 무엇이 포함되어야 하는지, 잘라낼 것보다 더 많은 내용이 명시되어 있습니다.

• S1. 로딩 잡음. "잠시만 기다려 주세요!", "숫자를 계산 중입니다…", "잠시만 기다려 주세요. 준비 중입니다." 읽을 만큼 충분히 긴 대기 시간이 아니라면, 무엇이 로딩 중인지 말하지 마세요. 그렇지 않으면 스피너나 스켈레톤만으로 충분합니다.
• S2. 성공 잡음. "성공적으로 저장되었습니다!", "변경 사항이 성공적으로 저장되었습니다." 결과를 전달할 수 있는 최소한의 단어로 표현하세요 ("저장됨", "초대가 [email protected]으로 전송됨"). 화면에 이미 결과가 표시되어 있다면, 토스트 메시지는 필요 없습니다.
• S3. 빈 상태 잡음. "아직 아무것도 없습니다!", "아직 프로젝트를 만들지 않은 것 같습니다. 첫 번째 프로젝트를 만들어 시작하세요!" 여기에 무엇이 있어야 하는지와 그것을 추가하는 하나의 액션을 말하세요.
• S4. 모호하거나 귀여운 오류. "이런! 문제가 발생했습니다", "오류가 발생했습니다. 나중에 다시 시도해 주세요." 무엇이 실패했고 사용자가 무엇을 할 수 있는지 말하세요. 코드가 무엇이 실패했는지 알 수 없다면, 그것을 명확히 말하고 재시도를 제공하세요.

허구 콘텐츠

• F1. 허구 증명. 사용자 수, 가동 시간 수치, 별점, 이름과 직함이 있는 사용 후기, "신뢰하는 기업" 로고 행, "소개된 곳". 프로젝트에 이에 대한 출처가 없다면, 출시된 페이지의 허위 주장입니다. 더 작은 허위 주장으로 다시 작성하지 마세요. 제거하고 보고서에 나열하여 소유자가 실제 데이터를 제공할 수 있도록 하세요.
• F2. 출시된 화면의 플레이스홀더 데이터. "John Doe", "Acme Corp", 로렘 입숨, example.com 주소, 기본 아바타 서비스. 픽스처, 테스트 및 스토리에서는 괜찮습니다. 출시된 화면에서는 작업으로 보고하세요. 실제 데이터를 제공할 수 없습니다.

장식

• D1. 상태가 없는 배지. 분위기를 위해 추가된 "NEW", "LIVE", "AI", "베타", "Pro", "인기". 앱이 추적하는 것을 반영하는 경우에만 배지를 유지하세요.
• D2. 상태 점. 텍스트 옆의 깜빡이거나 색깔이 있는 점. 실제 상태에 연결되고 접근 가능한 이름이 있는 경우에만 유지하세요.
• D3. 장식용 이모지 및 아이콘. 제목, 버튼, 레이블 및 목록 항목에서. 잘라내세요. 아이콘이 컨트롤인 경우( aria-label이 있는 아이콘 버튼) 또는 텍스트가 전달하지 않는 의미를 전달하는 경우에만 유지하세요.

차트 및 대시보드

• V1. 차트 유형을 명명하는 제목. "월별 수익 막대 차트"는 "월별 수익"이 됩니다. 당신 앞에 있는 데이터가 보여주는 경우에만 결과를 명시하세요("3월 이후 수익 두 배 증가").
• V2. 읽기 지침. "각 막대는 한 달을 나타냅니다", "세부 정보 보려면 가리키세요". 잘라내세요.
• V3. 두 번 말하기. 수량당 하나의 인코딩. 화살표, 백분율, "상승"이라는 단어 및 세 가지를 모두 다시 설명하는 문장이 있는 KPI는 숫자와 하나의 비교만 유지하세요.
• V4. 데이터와 경쟁하는 뼈대. 플롯 프레임, 진하거나 빽빽한 그리드선, 두꺼운 축 테두리, 3D, 마크의 그림자 및 광택. 잘라내거나, 유지해야 할 것은 가는 선으로 줄이세요. 동일한 차트 유형, 동일한 데이터, 동일한 계열 색상.
• V5. 직접 레이블이 작동하는 범례. 4개 이하의 계열이고 레이블을 붙일 공간이 있다면, 각 계열을 선의 끝이나 막대 옆에 이름을 붙이고 범례를 제거하세요.

표면 (요청 시에만)

먼저 references/surface.md를 읽으세요. 이 규칙이 전혀 적용되지 않는 디자인 의도(게임, 마케팅 페이지 또는 의도적인 디스플레이 타이포그래피가 있는 편집 레이아웃은 정규화해야 할 결함이 아닙니다)에 대한 확인으로 시작합니다.

• X1. 그라데이션 및 광택. 표면 및 버튼의 색조 간 그라데이션, 그라데이션 텍스트, 색깔 있는 광택, 흐릿한 색상 블롭.
• X2. 규모를 벗어난 간격. 형제 요소가 스케일을 사용하는 곳에서 mt-[13px] 또는 gap: 7px와 같은 일회성 값.
• X3. 실행 UI의 굵은 두께. 본문 텍스트, 레이블, 테이블 셀 및 컨트롤에서 800 및 900 두께. 디스플레이 제목은 범위를 벗어납니다.
• X4. 장식용 애니메이션. transition-all, 호버 시 확대되는 카드, 아무것도 설명하지 않는 바운스 및 루프.

유지하거나 다시 작성하는 문자열 수준 스타일(대소문자, 구두점, 잡음 단어, 일관성)에 대해서는 references/writing.md를 읽으세요. 작업된 전후 예시(텍스트를 유지하는 것이 올바른 편집인 경우 포함)에 대해서는 얼마나 잘라내야 할지 확실하지 않을 때 references/examples.md를 읽으세요.

가드레일

• 절대 사실을 추가하지 마세요. 다시 작성은 코드, 콘텐츠 파일, 데이터 또는 대화에 있는 것을 사용합니다. "편집 내용이 몇 초 내에 동기화됩니다"는 제품 주장이며, 당신은 그것이 사실인지 모릅니다. 정직한 다시 작성에 당신이 가지고 있지 않은 사실이 필요하다면, 줄을 잘라내거나 소유자를 위한 작업으로 나열하세요. 이것은 가장 쉽게 위반되는 규칙입니다. 왜냐하면 발명된 구체적인 내용이 그것이 대체하는 모호한 줄보다 더 읽기 좋기 때문입니다.
• 보이는 텍스트와 장식 요소만 변경하세요. 로직, 데이터, 색상, 서체 및 레이아웃 구조는 그대로 두세요. 예외는 요청 시 V4의 차트 뼈대와 표면 규칙입니다.
• 접근 가능한 이름을 유지하세요. 아이콘 버튼의 aria-label, alt, title 또는 스크린 리더 전용 텍스트를 절대 삭제하지 마세요. 잘라낸 보이는 텍스트가 유일한 접근 가능한 이름이었다면, 그것을 aria-label로 옮기세요.
• 텍스트를 소스에서 편집하세요. i18n 파일, props, 픽스처 또는 CMS의 문자열은 거기서 편집하거나 보고하세요. 컴포넌트에 하드코딩된 대체 텍스트를 넣지 마세요. 하나의 로케일 파일에서 문자열을 변경할 때, 다른 로케일을 작업으로 나열하세요; 요청받지 않는 한 직접 번역하지 마세요.
• 잘라낸 후 정리하세요. 이제 비어 있는 래퍼와 제거된 요소에 대해서만 존재했던 여백이나 간격을 제거하세요.
• 깨끗한 화면은 그대로 두세요. 테스트에 실패한 것이 없으면 아무것도 변경하지 마세요.
• 프로젝트를 따르세요. 프로젝트에 자체 음성 가이드, 용어집, 토큰 또는 디자인 시스템이 있는 경우, 이 스킬의 기본값이 아닌 그 방향으로 수정하세요.

절차

다음 단계를 추적하세요:

- [ ] 1. 누구와 하는 중: 한 줄
- [ ] 2. 카운트: python3 scripts/count_tells.py <target>      (요청 시 --surface 추가)
- [ ] 3. 보기: 가능하면 화면 스크린샷 찍기
- [ ] 4. 모든 상태의 모든 보이는 문자열과 장식을 읽고 테스트 적용; 실패를 규칙 ID로 태깅
- [ ] 5. 평결: 많음, 적음 또는 없음
- [ ] 6. 편집
- [ ] 7. 다시 카운트하고 다시 보기
- [ ] 8. 보고서

scripts/는 이 스킬의 폴더에 있습니다. 전체 경로로 스크립트를 실행하세요.

카운트. count_tells.py는 소스에 대한 정규식 검사입니다. 후보를 찾고 코드 시그니처가 있는 패턴에 대해 전후 숫자를 제공합니다. C3, C4, C5, C7, A2, V3 또는 의미에 의존하는 것은 볼 수 없으며, 합법적인 용도에 플래그를 지정합니다. 그 출력을 살펴볼 위치 목록으로 취급하세요. 남은 것이 의도적으로 유지된 것이라면 0에 도달하지 않는 카운트도 괜찮습니다.

보기. 소스는 사용자가 보는 것(어떤 문자열이 함께 나타나는지, 데이터에서 오는 것, 삭제가 레이아웃에 미치는 영향)을 숨깁니다. 브라우저나 스크린샷 도구가 있다면, 전후 화면을 캡처하세요. 둘 다 없다면, python3 scripts/screenshot.py <url-또는-html-파일> <out.png>를 Playwright가 설치된 곳에서 실행하세요. 사후 이미지에서 고립된 간격, 계층 구조를 잃은 제목 및 이동한 컨트롤을 확인하세요. 화면을 렌더링할 수 없으면 보고서에 그렇게 말하세요.

모든 상태를 읽으세요. 기본 보기는 인터페이스의 일부일 뿐입니다. 대상에서 로딩, 빈, 오류, 성공 및 비활성 분기, 토스트, 대화 상자 및 유효성 검사 메시지를 검색하세요. 현재 보기에는 없는 분기는 아래에 나열하고 "검토되지 않음"으로 표시하세요.

보고서

편집 결과에 다음 구조를 사용하세요. 특히 최종 사용자가 작동하기 위한 것(예: 저장되지 않음, 잘못된 동작)이 아닌 경우라도 아무것도 숨기지 마세요. 보고서에서 실행 취소해야 할 내용을 모두 볼 수 있고, 소유자가 모든 작업을 추적할 수 있습니다.

### UI declutter

**파일:** src/pages/dashboard.tsx 및 src/pages/dashboard.module.css
**범위:** 요약 페이지의 텍스트, 팝오버, 차트 및 축.
**절차:**
- [x] 1. 누구: 하루 15분 동안 여는 대시보드의 마케팅 책임자. 하는 중: 지난주 캠페인의 리드 합계와 전환율 확인.
- [x] 2. 전: 37개의 후보, 후: 14개
- [x] 3. 보기: dashboard-before.png, dashboard-after.png
- [x] 4. 읽기 및 테스트: 아래 태그 참조
- [x] 5. 평결: 중간 (지표 텍스트, 도움말 텍스트에서 눈에 띄게 정리됨. 차트 굵게는 유지됨).
- [x] 6. 편집: 아래 참조
- [x] 7. 후: 14개 (의도적인)
- [x] 8. 보고서

**테스트 결과:**
| 위치 | 규칙 | 전 | 후 | 비고 |
|---|---|---|---|---|
| 맨 위 "대시보드" 위의 "인사이트" | C1 | 제거됨 | | 제목이 중복됨 |
| "리드 합계" 아래의 "최근 전환…" | C4 | 제거됨 | | 차트가 동일한 정보를 플로팅함 |
| "내보내기"와 "CSV로 내보내기"가 같은 다운로드 메뉴에 있음 | A2 | "CSV로 내보내기"로 통일됨 | | 두 개의 라벨, 하나의 동작 |
| "(업데이트 중)" 배지 | C5 | 제거됨 | | 사용자가 참여할 수 없음 |
| 빈 차트: "데이터 없음" + "시작하기" 링크 | S3 | "데이터 없음"만 유지 | 설명 링크 제거됨(차트 유형이 다음 단계를 암시함) |
| 로딩 스켈레톤 | S1 | 유지됨 | 실행 중인 쿼리가 2개의 확인이 필요함 |
| 차트 제목: "지난주 캠페인 리드" | V1 | 유지됨 | 범례는 2계열만 있으므로 직접 라벨로 대체됨(V5) |

**작업:**
- [ ] 계정 관리자가 대시보드의 실제 데이터를 확인함 (꺾은선형 차트가 합계를 보여주는지 — 개발자는 확신하지 못함)
- [ ] es.json 업데이트 (de.json 및 fr.json은 작업으로 나열됨)
- [ ] 빈 차트 상태를 "데이터 없음"에서 "표시할 캠페인 데이터 없음"으로 변경 (설명, 좋은 S3). 현재 내용에서 잘라낸 것은 내부 회의를 위한 임시 텍스트였음.

변경 사항이 거의 또는 전혀 없는 경우:

### UI declutter — 최소

**파일:** src/components/ConfirmDialog.tsx
**평결:** 없음 — 테스트를 통과하지 못한 문자열이 없습니다. 대화 상자는 이미 확인 모범 사례를 따릅니다: 제목이 대상을 지정하고, 확인 버튼은 동사를 반복하며, 결과가 있는 경우 본문에 있습니다. 제안할 변경 사항이 없습니다.