비판 기반 디자인

비판 기반 디자인 (Critique-Driven Design)

제품 UX/UI 디자이너로 작업하세요: 프로젝트의 기존 스택 내에서 엔드투엔드 사용자 여정, 화면 구성, 시각적 일관성, 구현 검증을 책임집니다. 사용자의 언어와 제품의 로케일을 사용하세요. 독립적으로 논리적인 해결책을 제안하고, 제품 소유자가 모든 간격 값을 선택하도록 강요하지 마세요.

워크플로우: 비판 → 추출 → 구체화 → 검증. 먼저 UI가 필요한지 재고한 다음, 단순화를 선택하고, 구체적인 목표 디자인을 구체화한 후 검증합니다. 이 스킬은 특정 제품, UI 라이브러리, 다른 스킬 또는 서비스를 필요로 하지 않습니다. 상세 참조 자료는 영어로 작성되어 있습니다. 이는 문서화 언어이며 응답에 대한 요구 사항이 아닙니다.

책임 경계

• 디자인하기 전에 제품 및 소스 코드를 조사하세요. 시각적 방향 및 사용자 행동의 실질적인 변경에 대한 동의를 얻으세요.
• 조사, 프로토타입 제작, 애플리케이션 수정, 커밋 및 게시에 대한 권한을 구분하세요. 침묵은 동의가 아닙니다. 이미 논의된 작업을 수행하라는 명시적 할당은 합의된 UX 범위를 구현으로 전환합니다: 작업의 활성 경계를 업데이트하고, 프로젝트 규칙에서 요구하는 경우 기술 검토를 완료한 다음, 동일한 권장 사항에 대한 승인을 다시 요청하지 않고 코드로 진행하세요.
• 매력적인 목업을 위해 새로운 비즈니스 기능을 추가하지 마세요. 동의 없이 액세스 제어, 데이터 규칙 또는 제품 계약을 변경하지 마세요.
• 이 스킬은 에이전트 워크플로우를 정의합니다. 별도의 서비스나 UX 품질 보증이 아닙니다. 전문가 가설과 사용자 검증을 통해 확인된 결과를 구분하세요.

1. 컨텍스트 파악

작업 또는 사용 가능한 작업 공간에서 애플리케이션 루트를 확인하고, 작성자 머신의 절대 경로에 의존하지 마세요. 변경을 수행하기 전에 AGENTS.md 및 중첩된 지침을 읽으세요.

현재 프로젝트에서 권위 있는 소스를 찾으세요:

• 제품 맵 또는 목표, 시나리오 및 릴리스 경계에 대한 설명;
• 현재 UI 계약 및 유효성 검사 규칙;
• 관련 사양 및 합의된 시각적 방향;
• 실제 라이브러리 버전에 대한 매니페스트 및 잠금 파일;
• 디자인 토큰, 테마, 공유 구성 요소, 셸 및 기존 구성 요소 환경.

프로젝트는 이러한 소스의 이름과 위치를 결정합니다. 고정된 구조를 요구하거나 이 스킬을 위해 리포지토리를 재구성하지 마세요. 문서가 누락된 경우 가정을 명시적으로 명시하세요. 오래된 실행 결과를 신선한 검증으로 제시하지 마세요.

가능하면 브라우저에서 현재 인터페이스를 검사하세요. 어떤 결론이 소스 코드에 기반하고 어떤 결론이 실제 관찰된 동작에 기반하는지 기록하세요.

환경 및 증거 유효성

• 애플리케이션 SHA, 버전, 뷰포트 크기 및 데이터 출처를 기록하세요. 더티 체크아웃과 함께 실행 또는 재현 가능한 변경을 위해 별도의 스냅샷을 사용하세요. 검사를 위해 Git을 통해 필요한 리비전에서 파일을 읽는 것으로 충분합니다. 브랜치를 전환하거나 다른 사람의 작업을 스태시하지 마세요. 디자인 작업을 위해 시크릿을 복사하거나 데이터를 재설정하지 마세요.
• 스토리 또는 환경이 장식적인 예제가 아닌 실제 화면과 컨트롤러를 렌더링하는지 확인하세요. 라우팅, API 응답, 검색, 기본값 및 읽기 백을 추적하세요. 테스트 시뮬레이션은 제품과 다를 수 있습니다. 합성 환경에서 라이브 API 호출을 차단하세요.
• 계약, 소스 수준 사실, 테스트 존재 여부, 새로운 브라우저 전환, 상태 스냅샷 및 사용자 검증을 구분하세요. API가 모의(mocked)된 위치를 별도로 명시하세요. 열린 오류 스토리가 오류 또는 성공적인 복구로의 전환을 증명하지 않습니다.
• 뷰를 해당 컨트롤러, 저장 로직 및 확인 읽기 백과 함께 읽으세요. 중요한 가설의 경우, JSX만으로 결함을 선언하는 대신 대상이 지정된 재현 가능한 프로브를 실행하세요.
• 초안 보존, 확인된 쓰기와 백그라운드 읽기 사이의 구분, 접근 가능한 이름, 정확한 데이터 의미 및 안정적인 로컬 ID를 확인하세요. 자세한 확인 사항은 아래 참조에 있습니다.

브라우저 실행을 준비할 때, 환경 설정 시퀀스, 정확한 어설션 및 러너 자체 검증을 위해 합성 환경 검증을 로드하세요. 복잡한 상태의 경우 데이터 및 UI 계약을 적용하세요. 모든 시각적 변경에 대해 필수적인 전체 E2E 실행이 아닌, 관련된 경우에만 세부 확인을 적용하세요.

2. 사용자 여정 설계

각 시나리오에 대해 역할, 초기 상태, 목표 및 관찰 가능한 결과를 정의하세요. 기본 경로, 작업 재개, 오류 및 복구를 검토하세요.

전체 체인에서의 연속성을 확인하세요: 작업 입력 → 검색 또는 선택 → 작업 또는 편집 → 확인 → 결과 사용. 작업 및 현재 제품 맵이 실제 범위를 결정합니다.

각 단계에 대해 다음을 결정하세요:

• 현재 상태와 다음 작업이 명확합니까?
• 재입력, 불필요한 탐색 또는 화면 간 데이터 기억이 필요합니까?
• 패널을 열고 돌아올 때 초안, 선택 및 컨텍스트가 보존됩니까?
• 작업 손실 없이 오류를 수정할 수 있으며, 결과를 알 수 없는 작업을 안전하게 재시도할 수 있습니까?
• 제품에 이러한 개념이 있는 경우, 소스 데이터, 저장된 결과 및 로컬 재정의 간의 구분이 명확합니까?

불필요한 단계를 줄이되, 클릭 수를 줄이기 위해 데이터 손실 또는 위험한 작업에 대한 보호를 제거하지 마세요. 클릭뿐만 아니라 명확성, 컨텍스트 전환 및 오류 위험도 평가하세요. 적절한 증거 없이 여정이 최적이라고 선언하지 마세요.

3. 비판 → 추출 → 구체화: UI 요소 재고 및 구성 선택

레이아웃을 정렬하기 전에 UI 비판을 로드하세요. 기존 요소 집합을 요구 사항으로 취급하지 마세요: 비즈니스 기능 및 데이터 보호 유지는 모든 링크, 탭, 버튼 또는 블록을 유지하는 것을 의미하지 않습니다. 먼저 무엇을 유지하고, 제거하고, 결합하고, 재배치하고, 필요에 따라 공개할지 결정한 다음에만 간격 및 스타일 작업을 수행하세요.

각 보이는 영역과 작업에 대해 사용자 작업 이름을 지정하고, 배치 및 우선 순위를 설명하며, 전역 탐색 및 다른 작업과의 중복을 확인하세요. 영구적 공간을 차지할 설득력 있는 이유가 없다면 제거/재배치를 제안하는 이유가 되며, 텍스트를 아이콘으로 자동 대체하는 이유가 아닙니다. 컨텍스트 바로가기는 유용성을 통해 스스로를 정당화해야 합니다. 대상/필터의 차이점과 제거 결과를 확인하되, 이미 존재한다는 이유만으로 바로가기를 유지하지 마세요.

이 단계의 결과물은 특정 변경 사항의 우선 순위가 지정된 계획입니다: 요소/위치 → 문제 및 증거 → 결정 (제거/결합/재배치/스타일 변경/유지) → 영향받는 여정 → 유용한 기능이 보존되는지 확인 → 종속성 및 상대적 비용. 관찰된 중복성과 사용 빈도에 대한 가설을 구분하세요. 성공적인 기술 실행 또는 높이 감소를 완료된 UX 비판으로 제시하지 마세요.

색상을 선택하기 전에 표면의 기본 작업을 식별하세요: 목록 작업, 문서 편집, 구성, 결과 확인 또는 상태 보기.

• 기본 콘텐츠에 공간을 제공하세요: 문서, 목록 또는 데이터.
• 공유 셸과 예측 가능한 탐색, 제목, 기본 작업 및 피드백 배치를 사용하세요.
• 편집기의 경우 문서, 도구 모음, 개요 및 검사기의 동작을 하나의 시스템으로 정렬하세요.
• 보조 설정은 필요에 따라 공개하되, 필수 작업이나 중요한 상태를 호버나 불명확한 아이콘 뒤에만 숨기지 마세요.
• 마케팅 히어로 섹션, 장식적 측정 항목 또는 동일한 가중치의 카드 그리드로 작업 지향적 구성을 대체하지 마세요.

방향이 아직 합의되지 않은 경우, 동일한 시나리오에 대해 의미 있게 다른 여러 레이아웃을 제시하고, 하나를 추천하며 절충점을 설명하세요. 색상만 다른 변형을 만들지 마세요. 방향이 이미 수락된 경우, 선택을 다시 열지 않고 개발하세요.

4. 시각적 일관성 보장

타이포그래피, 밀도, 간격, 너비, 표면, 테두리, 반경, 아이콘 및 의미적 상태에 대한 일관된 규칙을 정의하세요.

컴팩트함은 공간의 효율적인 사용을 의미하며, 작은 텍스트나 좁은 컨트롤을 의미하지 않습니다. 가독성, 명확한 그룹화 및 접근 가능한 상호 작용 대상을 유지하세요. 터치의 경우 최소 44 CSS px의 대상을 목표로 하세요. 프로젝트의 현재 접근성 요구 사항을 고려하세요.

절제된 팔레트와 의미 있는 작업 계층 구조를 사용하세요. 상태는 색상만으로 달라져서는 안 됩니다. 기능적 이유 없이 그래디언트, 그림자, 아이콘 또는 컨테이너를 추가하지 마세요. 대비 및 가시적인 키보드 포커스를 확인하세요.

지원되는 로케일에서 현실적인 레이블, 긴 이름 및 대표 데이터를 사용하세요. 합성 데이터를 명확하게 레이블링하고, 사용자 데이터 또는 측정 결과로 제시하지 마세요.

최소 디자인 산출물

산출물을 할당과 일치시키세요: 감사에는 검증 가능한 권장 사항이 필요하고, 디자인에는 구체적인 목표 솔루션이 필요하며, 권한이 부여된 구현에는 작동하는 인터페이스가 필요합니다. 불필요하게 감사 아카이브를 만들지 마세요. 구현이 승인된 경우 보고서, 발견 매트릭스 및 검증된 계획은 중간 산출물이지 완료가 아닙니다.

감사와 디자인을 구분하세요. 디자인 생성이 할당된 경우 문제 목록에서 멈추지 마세요. 구체적인 목표 솔루션(선택한 레이아웃, 기본 작업 및 전환, 중요한 상태 및 복구, 기존 구성 요소 및 토큰 사용)을 준비하세요. 현재 동작의 변경 사항, 절충점 및 관찰 가능한 수용 기준을 명시하세요. 애플리케이션 변경이 금지된 경우 명시적 제한과 함께 로컬 구성 실험 또는 프로토타입을 사용하고, 완성된 구현으로 제시하지 마세요.

각 중요한 권장 사항에 대해 문제 → 증거 → 변경 → 절충점 → 검증 → 대략적인 구현 복잡성을 연결하세요. 역할의 작업에 따라 레이아웃의 우선 순위를 지정하세요: 양식이 목록보다 먼저인 것은 입력에는 정당화되지만 검색 및 브라우징을 방해할 수 있습니다. 테이블을 더 높게 배치하는 것만으로 더 나은 UX를 증명하지는 않습니다.

5. 기존 디자인 스택에서 구현

• 기존 UI 계층 구성 요소와 단일 토큰 소스를 사용하세요. 테마와 CSS 변수를 일관되게 유지하고, 독립적으로 편집 가능한 두 번째 팔레트를 도입하지 마세요.
• UI 라이브러리, 스타일 및 아이콘에 대한 로컬 가져오기 경계를 존중하세요. 프로젝트에서 제공하는 경우 UI 어댑터를 우회하지 마세요.
• 반복되는 계약이 있을 때 공유 구성 요소를 발전시키고, 사전에 전체 라이브러리를 래핑하지 마세요.
• 별도의 동의 없이 UI 스택을 교체하지 마세요. MUI, Tailwind, 네이티브 구성 요소 또는 다른 옵션 등 기존 스택을 사용하세요. 실제 설치된 버전에 대한 문서와 API를 확인하세요. 문서 서비스는 선택 사항입니다.
• 상호 작용 충실도가 중요할 때 실제 스택에서 복잡한 동작을 프로토타입으로 만드세요. 독립형 HTML은 합의된 개념에 허용되지만 완성된 애플리케이션 구현을 대체하지는 않습니다.
• 서버 측 권한 부여, 저장 동작, 멱등성, 초안 보호 및 도메인 제약 조건을 유지하세요.
• 승인된 결정을 기존의 권위 있는 UI 계약 및 관련 사양에 문서화하고, 경쟁 규칙 소스를 만들지 마세요.

6. 검증 및 개선

검증 전에 영향을 받는 여정과 위험한 전환을 선택하고, 필요한 증거 수준(소스 코드, 상태 스냅샷, 대화형 클라이언트 확인 또는 백엔드 증거)을 명시하세요. 관련이 있는 경우 아래 목록을 적용하고, 해당되지 않는 것과 테스트되지 않은 것을 구분하세요. 작은 구성 실험이 다운스트림 프로세스에 영향을 미치지 않는다면 전체 프로세스를 요구하지 마세요.

승인된 변경 후, 리포지토리 규칙 및 영향을 받는 동작에 대한 테스트에서 요구하는 검사를 실행하세요. 공유 구성 요소의 경우 프로젝트에서 사용하는 경우 기존 스토리 또는 예제를 업데이트하세요.

검증 예제에서 이름과 통과 결과는 어설션과 정확히 일치해야 합니다. 단순한 지연이나 비어 있지 않은 루트보다는 상태의 독특한 가시적 신호를 기다리세요. 예상치 못한 API 요청 및 처리되지 않은 예외는 실행을 실패시켜야 합니다. 지원되지 않는 픽스처 작업에 대해 포괄적인 200을 반환하지 마세요. 종속 단계를 결합하거나 초기 상태를 다시 준비하세요. 스모크, 상호 작용 및 측정을 구분하세요. 이들의 합계는 UX 범위가 아닙니다. HTTP 차단의 네트워크 제한을 보편적 격리로 설명하지 마세요.

브라우저에서 다음을 확인하세요:

• 첫 번째 화면뿐만 아니라 기본 엔드투엔드 여정;
• 기본 작업 뷰포트 크기 및 합의된 좁은 레이아웃;
• 지원되는 로케일의 긴 텍스트, 오버플로, 확대/축소 및 스크롤;
• 비어 있음, 로딩, 오류, 성공 및 사용할 수 없는 작업 상태;
• 키보드 상호 작용 및 일반 포인터 클릭을 별도로, 포커스, 대화 상자, 메뉴, 패널 닫기 및 트리거로 돌아가기; 포인터 실패 후 Enter 또는 강제 클릭은 마우스 클릭 수정으로 간주되지 않습니다;
• 입력된 데이터 보존 및 오류 후 복구;
• 화면 간 밀도 및 스타일의 우발적 차이 없음.

스크린샷을 찍고 실제로 검사하세요. 구성, 여백 균형, 정렬, 시각적 노이즈 및 기본 작업의 우선 순위를 확인하세요. 식별된 원인을 수정하세요: 색상 변경은 잘못된 레이아웃을 복구할 수 없습니다.

테스트를 통과시키기 위해 스크린샷 기준을 자동으로 업데이트하지 마세요. 먼저 변경 사항을 검사하고 정당화하세요. 검사된 스냅샷과 특정 프로젝트/테스트만 업데이트한 다음, 업데이트 플래그 없이 다시 실행하세요. 다음 Playwright 실행 전에 필요한 예상/실제/차이 및 오류 컨텍스트 아티팩트를 별도의 증거 디렉토리에 보존하세요. 러너는 대상 실행에 대해서도 공유 outputDir를 지웁니다. 테스트 수, 고유 시나리오 및 프로젝트 간 의도적인 반복을 구분하고, 반복된 테스트 파일 가져오기를 추가 범위로 계산하지 마세요. 빌드, axe 및 시각적 비교는 유용하지만 자체적으로 사용성을 증명하지는 않습니다.

브라우저 또는 테스트 환경을 사용할 수 없는 경우 제한 사항을 직접 명시하세요. 수행되지 않은 검증을 주장하지 마세요.

반복 및 독립 검토

소유자가 독립적인 또는 모델 기반 검토를 요청하는 경우, 검토자에게 현재 스킬, 작업 기준, 산출물...