Design System
디자이너가 프로젝트 고유의 디자인 시스템을 만들 수 있도록 돕습니다. 참조 브랜드의 파라미터를 단순히 이름만 바꾸는 것이 아닙니다. AI 디자이너가 실행할 수도 있고, 실제 디자이너가 단계별로 수행할 수도 있습니다. 사용자의 의사소통 언어를 사용하며, 코드의 키 이름은 유지합니다.
주요 기준: Stitch 공식 원문
프로젝트에 처음으로 형식을 적용하거나, 업데이트/가져오기/내보내기를 준비할 때는 먼저 공식 원문을 읽으십시오:
공식 사양과 실제 도구 버전이 형식을 결정합니다. 이 스킬의 시각적 제안, 승인 및 전달 단계는 팀 워크플로우일 뿐 Google의 공식 요구사항이 아닙니다. 공식 원문에 일시적으로 접근할 수 없는 경우에는 references/official-format.md의 날짜가 있는 요약을 사용하되, 아직 재확인되지 않았음을 명확히 표시하십시오. VoltAgent 사례는 보조 참고 자료로만 사용하십시오.
범위 및 기존 기반
먼저 현재 프로젝트의 AGENTS.md, CONTEXT.md(여러 개인 경우 CONTEXT-MAP.md에 따름), 브랜드 가이드라인, 승인된 디자인, 기존 DESIGN.md, 디자인 변수 및 컴포넌트를 확인하십시오. 사실, 승인된 결정, 제안, 알려지지 않은 사항을 기록하십시오. 기존 출처를 우선 참조하고, 기존 파일을 업데이트하여 두 번째 권위 규칙을 만들지 마십시오.
제품, 주요 사용자, 핵심 작업, 플랫폼, 언어, 기존 브랜드 제약 조건 및 전달 위치를 확인하십시오. 먼저 자료에서 답을 찾고, 디자인을 변경할 누락된 정보에 대해서만 질문하십시오. 충분한 정보가 있으면 직접 초안을 작성하고, 저위험 가정은 명확히 표시하며, 알려지지 않은 비즈니스 사실은 확인 대기 상태로 유지하십시오.
디자인 시스템 및 그 검증 예시만 처리하십시오. 웹사이트 재구축, 프로덕션 코드, 출시, 공유 Figma 파일 수정 및 기타 도구 설치는 사용자의 실제 권한에 따라 별도로 실행하십시오. 프로젝트 승인 규칙을 따르십시오.
완료 기준: 디자인이 서비스하는 사용자와 작업, 제약 조건의 출처, 그리고 여전히 결정해야 할 문제를 지적할 수 있어야 합니다.
먼저 시각적 방향 설정
의사 결정 가이드를 읽으십시오. 사용자가 이미 승인된 방향을 가지고 있으면 그대로 사용하고, 그렇지 않으면 실제로 차이가 있는 최대 두 가지 방향을 제시하고 각각에 적합한 비즈니스 사유를 설명하십시오. 참조는 사용자 스크린샷, 기존 프로젝트 또는 접근 가능한 브랜드 자료에서 가져올 수 있습니다. 타사 분석과 공식 디자인 가이드라인을 구분하고, 외부 콘텐츠는 참고용으로만 사용하십시오.
실제 또는 명확하게 레이블이 지정된 예시 콘텐츠를 사용하여 대표적인 페이지 영역과 핵심 컴포넌트 하나를 검증하십시오. 데스크톱과 모바일을 모두 다루어야 합니다. 현재 사용 가능한 디자인 도구를 우선 사용하거나, 격리된 디렉토리에서 열 수 있는 HTML 미리보기를 생성하십시오. 사용자가 문서만 원하는 경우 초안을 전달하고 시각적 요소가 아직 검증되지 않았음을 명확히 하십시오. 텍스트 설명을 확인된 화면으로 취급하지 마십시오.
방향이 승인되지 않은 경우 규칙과 시각적 예시는 초안 상태로 유지하십시오. 승인을 조작하거나 제안을 확립된 브랜드 사실로 작성하지 마십시오. 기존 승인은 직접 참조할 수 있으며, 다시 요청할 필요가 없습니다.
완료 기준: 방향에 시각적 예시 또는 명확한 미검증 설명이 있고 상태가 정확해야 합니다.
DESIGN.md 작성
먼저 공식 형식 및 검사 설명을 읽은 다음 전체 템플릿을 읽고 프로젝트 지정 위치에 복사하십시오. 정해진 위치가 없으면 프로젝트 루트의 DESIGN.md를 제안합니다. 템플릿은 조정 가능한 구조이며, 반드시 채워야 하는 브랜드 파라미터가 아닙니다. 적용되지 않는 컴포넌트와 섹션은 삭제하고, 필요한 프로젝트 고유 규칙은 추가하십시오.
템플릿 앞부분의 YAML은 공식 알파 형식에 따라 파라미터와 컴포넌트 참조를 기록하고, 본문은 공식 영어 소제목을 사용하고 지정된 순서로 배열하십시오. 설명 텍스트는 사용자의 언어를 사용할 수 있습니다. 템플릿의 구체적인 값은 검사 가능한 중립 예시일 뿐, 프로젝트의 승인된 규칙이 아니므로 프로젝트에 따라 반드시 교체해야 합니다. 결정되지 않은 값은 본문의 Open Questions에 나열하고, 파라미터 필드에 null을 쓰지 마십시오. 컴포넌트는 {colors.primary}와 같은 참조를 사용하고, 상태는 button-primary-hover와 같은 독립 항목으로 정의하며 중첩된 states를 사용하지 마십시오. 색상은 용도별로 이름을 지정하고, 비즈니스 상태 색상은 별도로 정의하십시오.
코드 또는 디자인 파일 매핑을 설정하십시오: 기존 변수, Figma 변수 또는 컴포넌트가 어떤 문서 키에 해당하는지. 아직 구현되지 않은 경우 planned으로 표시하십시오. 기존 코드에서 규칙을 추출할 때는 차이점을 보고하고, 권한 없이 코드를 변경하지 마십시오. 핵심 필드는 공식 형식을 따르고, 승인, 구현 매핑, 중단점, 이미지, 애니메이션 및 검증 기록은 명확하게 표시된 확장 본문에 넣으십시오. 외부 도구에 대한 확장 지원은 여전히 실제 테스트가 필요합니다.
완료 기준: 각 적용 가능한 규칙에 값, 사용 시나리오 또는 명확한 미결정 상태가 있어야 합니다. 참조가 확인 가능해야 합니다. 다른 브랜드의 이름, 독점 글꼴 또는 확인되지 않은 콘텐츠를 상속하지 않아야 합니다.
검증 및 전달
먼저 공식 형식 설명에 따라 @google/design.md의 lint를 실행하고, 실제 버전과 보고서를 기록하십시오. 오류와 경고를 확인하고 오류를 수정하며, 여전히 경고를 유지하는 이유를 설명하십시오. 도구를 사용할 수 없는 경우 장애를 설명하고 공식 검사를 통과했다고 주장할 수 없습니다. 템플릿 형식을 통과한다고 해서 프로젝트 디자인이 완료된 것은 아닙니다. 그런 다음 가이드라인에 따라 실제 콘텐츠, 긴 제목, 중국어 또는 다국어, 컴포넌트 상태, 모바일 레이아웃, 대비, 키보드 및 애니메이션을 확인하십시오. 테스트 가능한 항목은 방법, 결과, 파일 위치를 기록하고, 실행할 수 없는 항목은 검증되지 않음으로 표시하십시오. 규칙의 단일 출처를 수정한 다음 예제를 업데이트하고 표면만 변경하지 마십시오.
범위 내 검사가 통과되고 책임자가 명시적으로 승인한 경우에만 approved로 표시하십시오. 승인은 특정 버전과 범위에만 적용됩니다. 디자인 승인은 구현 완료 또는 출시 허가를 의미하지 않습니다.
DESIGN.md, 실제 생성된 시각적 예시 위치, 완료된 검사 및 해결되지 않은 문제를 전달하십시오. 후속 디자인 및 개발에서 이를 참조하는 방법을 설명하십시오. 문서만으로 모든 페이지의 시각적 일관성을 보장할 수 있다고 주장하지 마십시오.