Better Design

Better Design은(는) 무엇을 하나요?

요청된 작업을 명확하고 실행 가능하게 만드십시오: 사용자는 현재 위치를 파악할 수 있고, 작업을 활성화하기 전에 이해하며, 결과를 받고, 오류에서 복구할 수 있습니다. 일관성, 표현력 및 접근성을 별도로 평가하십시오. 완벽한 UX를 약속하지 마십시오.

1. 범위 및 시각적 근거 설정

• 모드를 선택하십시오: 생성, 집중 개선, 감사 또는 계획. 감사는 읽기 전용으로 유지하고, 계획에서는 변경 사항을 구현하지 마십시오. 사용자가 요청하지 않은 기능을 추가하지 마십시오.
• 요청 및 프로젝트에서 플랫폼을 설정하십시오. 컨텍스트가 없는 경우에만 반응형 웹, 시맨틱 HTML 및 WCAG 2.2 AA를 초기 대상으로 사용하십시오.
• 반응형 표면을 구성하거나 변경하기 전에 실제 기기 및 뷰포트 매트릭스를 정의하십시오. 웹사이트의 경우 제품이 지원하는 모바일, 태블릿, 데스크탑 및 울트라와이드 레이아웃을 포함하고, 모바일 게임의 경우 소형 및 일반 휴대폰과 태블릿을 포함하십시오. 디자인 제약 조건과 레이아웃 동작은 데스크탑 구성을 단순히 축소하는 것이 아니라 해당 표면에 적응해야 합니다. 브라우저 작업의 경우 브라우저 확대/축소를 매트릭스에 포함하십시오. 75%, 100% 및 150%에서 다양한 클리핑, 밀도, 리플로우 및 상호작용 실패가 노출될 수 있기 때문입니다.
• UI 작업 전에 프로젝트의 DESIGN.md(루트, docs/, design/ 또는 에이전트 지침에 명명된 경로)를 찾아 완전히 읽으십시오. 이는 인터페이스 값(글꼴, 서체 배율, 색상 역할, 간격, 반경, 구성 요소 크기, 아이콘 및 모션)의 단일 소스입니다. 새 코드 또는 변경된 코드의 모든 값을 역할 또는 토큰 이름으로 가져오고, 절대 눈대중, 반올림 또는 유사 중복을 도입하지 마십시오. 규칙은 design-md.md에 있습니다.
• 현재 런타임 또는 확인된 현재 캡처를 통해 기존 화면을 검사한 다음, 주변 구성 요소, 토큰, 스타일 및 프로젝트 규칙을 검사하십시오. DESIGN.md가 없다고 해서 디자인 시스템이 없는 것은 아닙니다. 코드 토큰이 시스템입니다. 관련 없는 진행 중인 작업을 보존하십시오.
• 구현 결함과 재설계 요청을 구분하십시오. 먼저 원인을 해결하십시오: 불명확한 순서, 예측할 수 없는 동작, 피드백 부족, 데이터 손실 또는 콘텐츠 손실.
• 다음 순서로 결정을 내리십시오: 명시적 작업 및 제약 조건 → DESIGN.md 및 기존 시스템 → 플랫폼 관례 → 도메인 작업 → 이 스킬의 구성 가능한 기준선. 기능성 및 해당 접근성 요구 사항은 모든 수준에 적용됩니다.
• 기본 시각적 방향. 사용자가 시각적 스타일을 명명하지 않고 프로젝트에 DESIGN.md, 브랜드, 코드 토큰 또는 상속할 라이브 UI가 없는 경우 하우스 스타일로 구축하십시오: Apple 정신의 프리미엄 초미니멀(검정 캔버스, 500 및 340 두께의 거의 흰색 Geologica, 두 가지 회색, 링크 및 포커스를 위한 하나의 파란색, 필 동작, 톤으로 분리된 표면, 유일한 색상으로서의 실제 콘텐츠). 규칙 및 준비된 DESIGN.md 사전 설정은 house-style.md에 있습니다. 스타일을 작성하기 전에 전체를 읽으십시오. 두 가지 오독으로 인해 에이전트가 다른 곳으로 이동하므로 명시적으로 확인하십시오(house-style.md 섹션 1): 제품의 도메인, 산업, 대상 또는 이름은 시각적 단서가 아니며("커피 로스터리", "개발자용"), 건드리지 않은 스캐폴드 기본값은 상속할 시스템이 아닙니다(shadcn/ui 기본 테마, Tailwind의 기본 팔레트, create-next-app, Vite 또는 Expo 스타터, Bootstrap, MUI 또는 Chakra 기본값). 대신 하우스 스타일을 매핑하십시오. 적용되는 경우 참조 파일 house-style.html에서 시작하고 빈 페이지에서 시작하지 마십시오. 토큰, 유형 클래스, 내비게이션, 버튼, 타일 및 섹션 리듬을 가져온 다음(또는 스택의 구성 요소로 포팅) 콘텐츠를 교체하십시오(house-style.md 섹션 1). 사용자의 시각적 단서(색상, 분위기, 테마, 참조, 브랜드, 대상 스타일)가 이를 재정의합니다. 요청을 따르고 요청이 열어두고 모순되지 않는 하우스 스타일의 부분만 적용하십시오. 요청하지 않는 한 기존 제품을 하우스 스타일로 다시 스타일링하지 마십시오. 게임은 자체 아트 디렉션을 유지합니다.
• 설정된 브랜드, 밀도, 게임 같은, 편집 또는 표현 구성을 유지하십시오. 일반적인 회색 CRM으로 대체하지 마십시오. 실제 충돌의 경우 가장 작은 접근 가능한 조정을 선택하고 특정 편차를 설명하십시오.
• 결정을 실질적으로 변경하는 알려지지 않은 사항만 명확히 하고, 합리적인 가정을 간결하게 명시하십시오. 이 스킬은 새로운 승인 또는 HTML 게이트를 도입하지 않습니다. 프로토타입, 승인 및 빌드에 대한 기존 프로젝트 요구 사항은 계속 적용됩니다.

2. 작업 및 비례적 계약 정의

• 기본 시나리오를 일반 언어로 설명하고 관찰 가능한 결과를 설명하십시오. 시작 → 동작 → 결과 → 오류/재시도 → 뒤로/취소 과정을 살펴보십시오.
• 기본 작업, 보조 작업 및 도움말을 분리하십시오. 사용자에게 친숙한 이름과 패턴을 선택하고, 화면 전반에 걸쳐 내비게이션 및 동작 위치를 일관되게 유지하십시오.
• 단일 수정에는 변경된 결정 및 검사에 대한 짧은 기록만 있으면 됩니다. 새 흐름의 경우 구현 전에 간결한 계약을 작성하십시오. 이는 작업 도구이지 사용자를 위한 필수 문서가 아닙니다.
• 구조, 숫자 기본값 및 예외는 design-contract.md를 사용하십시오. JSON 예제는 형식을 보여줍니다. 작은 변경을 위해 프로젝트에 전체를 추가하지 마십시오.
• 계약을 플랫폼, 목표, 기존 시스템, 방향, 영향을 받는 구성 요소, 해당 동작/상태, 반응형 동작 및 수용 증거로 제한하십시오. 계획된 검사는 완료된 검사가 아닙니다.

3. 스타일링 전에 아트 디렉션 설정

부정적인 규칙은 출력을 다음 가장 일반적인 템플릿으로만 이동시킵니다. 캐릭터는 프로세스에서 비롯됩니다. 정체성이 작업의 일부인 표면(브랜드, 랜딩, 포트폴리오, 소비자 앱, 게임, 편집, 실행기)을 생성하거나 재설계할 때는 art-direction.md를 따라 토큰을 선택하기 전에 수행하십시오. 하우스 스타일이 적용되는 경우(섹션 1), 팔레트, 유형, 모양 및 모션 토큰은 사전 설정에서 제공됩니다. 여전히 개념을 작성하고 이미지, 각 섹션의 주요 요소 및 하나의 시그니처 세부 사항(house-style.md 섹션 10)을 선택하도록 하십시오. 그렇지 않은 경우:

• 제품의 도메인, 대상 및 콘텐츠에서 한 문장 개념을 도출하십시오. 그 세계의 대상, 장소 또는 공예품 - "현대적, 깔끔한, 미니멀"과 같은 형용사에서 비롯된 것이 아닙니다. 세 가지 목표 품질과 세 가지 구체적인 반품질을 추가하십시오.
• 3-5개의 실제 참조(사용자가 제공한 것을 우선, 절대 AI 생성 이미지 아님)를 수집하고 각각에서 정확히 무엇을 가져올지 기록하십시오: 리듬, 밀도, 숫자 표시, 재료, 빛.
• 주요 장치(타이포그래픽, 이미지 주도, 구조적)가 다른 2-3개의 방향을 스케치한 다음, 작업 및 대상과 관련된 이유로 하나를 선택하십시오.
• 개념에서 팔레트와 유형을 도출하십시오: 명시된 기원과 색조가 있는 중성 색상이 있는 팔레트; 세 가지 유형 후보와 합리적인 선택. 하나 또는 두 개의 시그니처 세부 사항을 계획하십시오; effects-library.md의 선택적 풀에는 테스트된 것이 있습니다.
• 동일한 개념에서 모션 캐릭터를 도출하십시오: 그 세계에서 사물이 움직이는 방식(템포, 무게, 물리, 스프링 여부)과 하나의 시그니처 모션 세부 사항. 팔레트, 유형 및 모션은 하나의 목소리로 읽혀야 합니다; motion.md를 참조하십시오.
• DESIGN.md, 기존 브랜드 또는 방향이 상속된 디자인 시스템 내에서: DESIGN.md에서 가져오거나 라이브 표면에서 한 문장으로 명시하고 그 안에서 작업하십시오. 밀도가 높은 작업 도구는 정밀성과 데이터 타이포그래피를 통해 캐릭터를 표현합니다. 시스템이 없고 사용자 단서가 없으면 중립 대체의 밀도로 하우스 스타일의 앱 배율과 팔레트를 사용합니다.
• 계약(direction, direction.motion 포함)에 방향을 기록하고 distinctiveness 및 motion 검사를 계획하십시오. 선택한 방향과 해당 토큰을 DESIGN.md에 기록하여 나중 화면과 세션이 동일한 값에서 빌드되도록 하십시오.

4. 일관된 의사 결정 시스템 구축

• DESIGN.md 및 코드 토큰의 토큰과 구성 요소를 재사용하십시오. 새 시스템의 경우 색상, 타이포그래피, 간격, 반경, 레이어 및 모션에 대한 의미론적 역할을 정의한 다음 구성 요소 변형을 선택하십시오.
• 모든 화면이 동일한 부분(하나 또는 두 개의 글꼴 패밀리, 몇 가지 역할의 단계적 서체 배율, 고정 간격 배율, 몇 가지 반경 및 고정 구성 요소 크기(예: 버튼 sm/md/lg))으로 구축되도록 세트를 닫아 두십시오. 동일한 역할, 모든 화면에서 동일한 값. 누락된 값은 시스템 결정입니다. 동일한 변경으로 DESIGN.md 및 코드 토큰에 역할을 추가하십시오.
• 인터페이스를 처음부터 생성할 때(하우스 스타일이 적용되는 경우 house-style 사전 설정에서) 또는 재설계 또는 다중 구성 요소 변경에서 찾을 수 없는 경우 템플릿에서 DESIGN.md를 생성하십시오. 값을 발명하지 않고 라이브 코드 토큰에서 파생시키고, 자동으로 수정하지 않고 모순을 기록하십시오. 요청하지 않는 한 단일 요소 수정을 위해 생성하지 마십시오. 한 줄로 제안하십시오. DESIGN.md와 코드 토큰을 둘 중 하나를 건드리는 모든 변경 내에서 동기화 상태로 유지하십시오.
• API는 의도, 크기, 밀도 및 상태를 표현합니다. 기본 props, 양식 참여, 링크 및 접근 가능한 이름을 보존하십시오. 제출 버튼이나 href가 있는 링크에 onClick을 요구하지 마십시오.
• 모든 요소를 자체 16진수, 간격, 그림자 및 반경으로 조정하지 마십시오. 원인이 공유되는 경우 공유 토큰 또는 변형을 변경하십시오. 레이아웃 수학, 1px 테두리, 0, fr, %, calc, aspect-ratio 및 허용된 프로젝트 값은 그 자체로 위반이 아닙니다.
• 역할과 컨테이너에 따라 텍스트 크기를 선택하십시오.
• 형상을 구성하고, 절대 눈대중으로 배치하지 마십시오. 모든 화면, 패널 및 게임 메뉴에 대해 layout-geometry.md를 따르고 결과를 측정하십시오(섹션 8). 정렬 불량을 원인(피벗, 앵커, 누락된 레이아웃 그룹, 스프라이트 패딩, 글꼴 메트릭)에서 수정하고, 요소 하나를 밀어서 수정하지 마십시오:
  • 동일한 간격. 한 종류의 형제는 하나의 간격 토큰으로 레이아웃 컨테이너(flex/grid gap, Unity 레이아웃 그룹, Godot 상자 컨테이너, UMG 상자)에 배치되므로 그들 사이의 모든 간격은 동일합니다. 다른 간격은 새 그룹과 배율의 명확한 단계를 의미해야 합니다. 근접 사다리: 컨트롤 내부 < 항목 간 < 그룹 간 ≤ 패딩.
  • 공유 라인. 행의 항목은 상단/중앙/하단을 공유합니다(혼합 높이는 중앙 공유). 열의 항목과 설정 목록의 모든 레이블은 하나의 수직 키라인에서 시작하고 컨트롤은 두 번째 키라인에 있습니다. 그리드 또는 고정 레이블 열을 사용하고 행당 오프셋을 사용하지 마십시오. 버튼 세트는 하나의 크기를 공유합니다.
  • 작은 컨트롤 내부 콘텐츠는 보이는 잉크(대문자 높이, 자른 아이콘 픽셀)로 중앙에 배치되고 글꼴 라인 상자 또는 패딩된 스프라이트 사각형이 아닙니다. 비대칭 아이콘은 구성 요소에 내장된 선언된 광학 오프셋을 얻습니다. 아이콘 + 레이블 쌍은 하나의 간격 토큰을 사용합니다.
  • 숨 쉴 공간. 아무 것도 오버플로되거나 컨테이너 가장자리에 있지 않습니다. 패딩은 포함된 간격보다 적어야 하며, 가장 긴 지역화, 호버 배율 및 포커스 링을 위한 예비 공간이 있습니다. 대화형 UI는 지원되는 모든 화면 비율에서 안전 영역 내부에 유지됩니다. 콘텐츠가 맞지 않으면 여백이 아닌 레이아웃을 변경하십시오.
• 블랙리스트가 아닌 프로세스를 통해 타이포그래피를 선택하십시오: 개념(시대, 재료, 목소리, 데이터 밀도)에서 파생된 세 가지 패밀리를 숏리스트한 다음, 명시된 이유로 선택하십시오. 패밀리는 실제 크기와 언어에서 읽기 쉬워야 하며 필요한 굵기, 스타일, 숫자, 글리프 범위(지원되는 경우 키릴 문자 포함) 및 대체 동작을 제공해야 합니다. 금지된 패밀리는 없지만, 습관적으로 선택된 패밀리는 결함입니다: 이유 없이 하나의 트렌드 기본값(Inter, Uni Sans)을 다음(Space Grotesk, DM Sans, Instrument Serif)으로 교체하는 것은 동일한 템플릿입니다. 세련된 유형은 인터페이스를 더 읽기 어렵게 만들어서는 안 됩니다.
• 지배력과 대비를 통해 계층 구조를 구축하십시오: 화면 또는 섹션당 하나의 주요 요소, 명확하게 단계화된 서체 배율(표현적인 표면에서 display 3-5× body, 밀도가 높은 도구에서 더 작은 단계), 개념에 도움이 되는 의도적인 비대칭, 하나의 블록 패턴을 반복하는 대신 구조가 다른 인접 섹션.
• 황금비는 구성, 계층 구조, 자르기 또는 공백을 개선할 때 비율, 계층 구조, 자르기 또는 공백에 정보를 제공할 수 있지만, 필수 공식보다는 시각적 도구입니다. 충돌할 때마다 실제 작업, 콘텐츠, 반응형 제약 조건, 가독성 및 기존 시스템을 선호하십시오.
• 기본 화면을 중단되지 않는 산문의 벽으로 만들지 마십시오. 콘텐츠가 동작, 그룹화 또는 시각적 앵커를 통해 이해될 수 있는 경우. 밀도가 높은 설명을 스캔 가능한 섹션으로 나누고, 유용한 경우 의미 있는 컨트롤, 아이콘, 일러스트레이션, 미리보기, 다이어그램 또는 기타 작업 관련 이미지와 쌍을 이루십시오. 예를 들어 대시보드 또는 계정 영역은 사용자가 구성할 수 있는 내용만 설명하는 것이 아니라 주요 섹션과 다음 작업을 노출해야 합니다. 이해를 방해하거나 잘못된 어포던스를 생성하는 장식적인 시각 자료를 추가하지 마십시오.
• 의미와 강조를 위해 색상을 사용하고, 색상만으로 상태를 전달하지 마십시오. 오류/성공/필수/선택 정보를 텍스트, 아이콘, 모양, 패턴 또는 회색조 및 색각 결핍에 대해 표시되는 다른 비색상 단서와 쌍을 이루십시오.
• 불투명도, 오버레이, 그라디언트, 이미지 및 필요한 모든 테마가 적용된 후 실제 인접 전경/배경 쌍에서 대비를 확인하십시오. 임계값에 가까운 결과를 반올림하지 마십시오. 일반 텍스트 및 텍스트의 의미 있는 이미지의 경우 최소 4.5:1, 큰 텍스트(최소 24 CSS px 일반 또는 18.5 CSS px 굵게)의 경우에만 3:1을 충족하십시오. 가늘거나, 작거나, 특이한 유형의 경우 더 높은 값을 목표로 하십시오.
• 활성 컨트롤, 포커스 또는 상태 및 의미 있는 그래픽 개체를 인접한 색상과 식별하는 데 필요한 시각적 정보에 대해 최소 3:1 대비 비율을 보장하십시오. 테두리는 컨트롤을 식별 가능하게 만드는 경우에만 필요합니다. 해당 목적으로 사용되는 경우 동일한 3:1 대비 비율을 충족해야 합니다. 동일한 역할을 가진 인접 구성 요소 간의 시각적 구분을 위해, 평균적으로 구분되는 가장 어두운 인접 쌍이 적절한 대비(에지가 구분 가능하고 오버플로가 발생하지 않음)를 갖도록 하십시오. 하드 번호를 할당하는 대신 측정 기준을 설정하십시오. 모든 곳에서 수직 리듬은 간격 배율과 일치합니다. 목록, 양식 및 데이터 테이블은 일관된 줄 간격과 간격을 가집니다. 내비게이션 상태는 활성, 포커스, 호버, 방문 및 비활성을 읽기 가능한 방식으로 신호를 보냅니다. 활성 내비게이션 표시기는 활성 섹션에 해당합니다. 각 토글 또는 확인란은 선택 및 선택 취소 상태에 대해 식별 가능한 시각적 표시기를 가집니다. 비활성화된 컨트롤은 여전히 읽을 수 있고 배경과 구별 가능합니다. 아이콘, 이미지 및 그래픽이 표시되는 모든 곳에서 후광 및 대비 규칙이 적용됩니다. 모달 오버레이는 배경 콘텐츠를 읽기 어렵게 만들 수 있는 충분한 불투명도를 가지지만 완전히 숨기지는 않습니다. 모달이 열려 있을 때 배경 콘텐츠는 상호작용할 수 없습니다(스크롤 차단 및 포커스 트랩). 모든 상호작용 영역은 키보드를 통해 접근 가능하고 포커스 가능합니다. 터치 대상은 지침 또는 플랫폼 요구 사항보다 작지 않습니다.