Protonicwave/web-ui-craft

Web UI craft

일반적인 UI는 스타일이 아닙니다. 그것은 아무도 결정하지 않은 모든 선택을 채우는 것입니다: 모델, 템플릿, 프레임워크가 가장 일반적인 답을 제공하고, 그 결과는 어떤 제품에도 속할 수 있습니다. 가장 보기 좋은 사이트(Linear, Vercel, Stripe, Family, Awwwards 수상작)는 거의 아무것도 기본값에 맡기지 않습니다. 그들은 작은 시스템을 계산하고, 하나의 아이디어에 집중하며, 기능적 세부 사항을 측정 가능한 기준으로 유지합니다.

따라서 작업은 결정을 내리고, 그것을 기록하며, 각 결정을 주제, 사용자 또는 지각의 물리 법칙에 연결하는 것입니다. 아래 다섯 단계를 순서대로 따르세요. 작업 규모에 맞게 조정하세요: 단일 버튼은 한 문장의 브리핑과 빠른 비평으로 충분하고, 랜딩 페이지는 전체 과정을 적용합니다.

1. 주제 읽기

시각적 선택 전에 다음을 확립하세요:

• 주제: 제품, 조직 또는 콘텐츠가 실제로 무엇인지, 그리고 그것이 속한 세계(산업, 재료, 어휘, 인공물).
• 대상: 누가 도착하는지, 그들이 이미 무엇을 알고 있는지, 어떤 기기를 사용할 가능성이 높은지.
• 주요 작업: 페이지나 화면이 반드시 수행해야 하는 한 가지. 다른 모든 것은 이에 종속됩니다.
• 기존 제약 조건: 브랜드 자산, 기존 디자인 시스템, 토큰, 컴포넌트 라이브러리 또는 저장소의 프레임워크. 토큰이 존재한다면 그것을 사용하고 이 스킬을 그 안에서 적용하세요. 요청받지 않는 한 확립된 제품에 새로운 정체성을 부과하지 마세요.

사용자가 제공한 정보가 거의 없다면, 주제에서 유추하고 브리핑에 가정을 명시하고 질문 목록을 던지지 마세요.

2. 디자인 브리핑 작성

코드를 작성하기 전에 응답에 간결한 브리핑을 작성하세요. 그것이 디자인이므로, 다른 사람이 그것만으로도 동일한 것을 구축할 수 있을 만큼 구체적이어야 합니다.

방향(Direction):    명명된 미학과 그것이 이 주제에 맞는 이유 (한두 줄)
시그니처(Signature): 이 페이지가 기억될 하나의 아이디어, 그것을 전달하는 히어로 조각, 그리고 그 조각이
              어떻게 만들어질지 (제공된 자산, 생성된 이미지, 또는 코드로 구축)
팔레트(Palette):    중성 (... 쪽으로 색조), 하나의 악센트 (역할), 의미 색상; OKLCH 값
타이포그래피(Type):  각각의 패밀리와 역할 (디스플레이, 텍스트, 필요시 모노), 그리고 각각이 주제와 공유하는 것;
              디스플레이 타입이 구성 내에서 어떻게 작용하는지; 스케일 비율; 본문 크기
레이아웃(Layout):   첫 화면에 대한 두세 가지 옵션, 각각 한 줄 컨셉과 ASCII
              와이어프레임; 선택된 하나와 그 이유; 그리드, 측정(measure), 밀도, 섹션 리듬
깊이(Depth):       표면이 분리되는 방식 (톤 단계, 헤어라인, 그림자), 빛이 어디서 오고
              무엇에 떨어지는지
모션(Motion):      계층 (제품 또는 브랜드), 시그니처 순간과 그 리드 요소, 무엇이
              얼마나 오래 움직이는지, 그리고 의도적으로 움직이지 않는 것
이미지(Imagery):   사진, 일러스트레이션, 3D, 제품 UI 또는 타이프 전용; 한 줄의 아트 디렉션
카피(Copy):        헤드라인과 주요 행동, 이 대상에 맞게 작성됨; 행동의 이름,
              버튼부터 확인까지 일관되게 유지
예산(Budget):       전체 페이지에 대한 압축 스크립트와 스펙타클 계층이 차지할 수 있는 비율
              (기본적으로 총 365 KiB; 스펙타클이 없는 페이지의 경우 75 KiB)

브리핑 규칙:

• 도출하되, 장식하지 마세요. 각 줄은 "왜 이것이, 이 주제에 대해?"에 답합니다. 제품의 재료에서 가져온 팔레트, 그 언어에서 가져온 서체, 세계에서 가장 특징적인 것으로 시작하는 히어로.
• 하나의 시그니처, 나머지는 조용하게. Stripe은 그래디언트 웨이브를, Apple은 스크롤 스크러빙된 제품 샷을, Family는 나는 트레이를 가지고 있습니다. 대담함은 한 번만 사용하세요. 주변의 절제가 그것을 돋보이게 만듭니다.
• 절제는 유효한 방향입니다. 하나의 악센트를 가진 차분하고, 타이프 주도적이며, 모노크롬 시스템은 WebGL 히어로만큼 의도적이며, 일반적으로 도구와 문서에 적합한 선택입니다.
• 조용함이 텅 빔은 아닙니다. 절제는 페이지가 가진 아이디어의 수를 제한할 뿐, 각각이 얼마나 풍부한지는 제한하지 않습니다. 시그니처는 오래 볼수록 보상을 주어야 합니다: 이 주제를 위해 그려진 일러스트레이션, 세심하게 배치된 실제 데이터, 텍스처, 실제 디스플레이 규모의 타이프. 음식, 문화, 소비재 및 브랜드 주제는 일반적으로 이미지나 일러스트레이션이 따뜻함을 전달해야 하므로, 이들 중 하나에 대한 타이프 전용 페이지는 명시된 이유가 필요합니다.
• 히어로 조각에 노력을 집중하세요. 호평받는 사이트는 많은 규칙을 어기면서도 여전히 고급스러워 보이는데, 그 이유는 한 조각이 매우 높은 기준으로 만들어졌기 때문입니다: 믿을 수 있는 데이터가 있는 제품 화면, 조명이 비춰진 물체, 소유한 일러스트레이션. references/artefacts.md를 사용하여 선택하고 구축하세요. 회색 막대가 있는 둥근 상자는 제품 샷이 아닙니다.
• 타이프는 구성을 위한 담체가 아니라 구성의 일부입니다. 디스플레이 크기에서 설정은 디자인입니다: 페이지에서 가장 작은 텍스트에 대한 규모, 두께, 너비, 대소문자, 줄바꿈 위치, 헤드라인이 무엇에 대해 배치되는지. 64px 헤드라인 위에 12px 인터페이스 텍스트를 배치하는 Linear의 방식은 그 효과의 큰 부분입니다.
• 레이아웃을 선택하기 전에 비교하세요. 진정으로 다른 두세 가지 첫 화면(이미지만 이동된 하나의 레이아웃이 아닌)을 스케치하고 주제의 주요 작업으로 선택하세요. 가장 먼저 떠오르는 레이아웃은 일반적으로 템플릿입니다.
• 주장, 증거, 행동. 대부분의 페이지에는 하나의 명확한 진술, 하나의 실제 증거(제품 보기, 실시간 숫자, 고객, 데모) 및 하나의 주요 행동이 필요합니다. 구조는 템플릿이 아닌 콘텐츠를 따릅니다.
• 행동당 하나의 이름. "게시"라고 말하는 버튼은 "저장됨"이 아닌 "게시됨"이라고 말하는 확인을 생성합니다. 인터페이스의 어휘는 사람들이 주변을 탐색하는 방법입니다.

방향이나 시그니처를 선택할 때는 references/exemplars.md를, 팔레트, 타이포그래피, 레이아웃 및 깊이를 설정할 때는 references/visual-system.md를, Motion 라인을 작성할 때는 references/interaction.md의 모션 섹션을 참조하세요.

3. 브리핑 검증

구축하기 전에, 공격하세요:

• 교체 테스트. 경쟁사의 이름을 아무도 눈치채지 못하게 이 이름 대신 넣을 수 있습니까? 그렇다면 브리핑이 아직 결정을 내리지 못한 것입니다.
• 선택별 테스트. 모든 줄에 대해, 그것이 어떤 제품에나 속할 수 있는지 물어보세요. 그렇다면, 그것은 아래 빌드 시트의 의도적이고 잘 조정된 기본값이어야 하거나 변경되어야 합니다.
• 수렴 테스트. 인접한 주제에 대해 작성할 브리핑을 몇 줄로 스케치하세요: 같은 카테고리의 다른 도구, 같은 업계의 다른 제작자. 동일하게 나오는 모든 줄은 기본값일 뿐, 결정이 아닙니다. 변경하고, 브리핑에 무엇이 변경되었고 그 이유를 명시하세요. 두 주제가 공유하는 사실(두 제품 모두 하드웨어, 두 대상 모두 코드를 읽음)에서 비롯된 경우에만 줄을 유지할 수 있습니다. 해당 사실을 명명하세요.
• 'AI 티' 확인. references/slop-tells.md (전체적인 느낌 클러스터 포함)와 비교하세요. 하나의 기본값을 다음으로 가장 일반적인 기본값으로 교체하지 마세요(Inter를 Space Grotesk로, 보라색을 청록색으로). 이유가 있는 선택으로 대체하세요.

브리핑을 수정한 다음 구축하세요.

4. 구축

• 토큰 우선. 모든 컴포넌트 전에 팔레트, 타이포그래피 스케일, 간격, 반경, 그림자 및 모션을 CSS 사용자 정의 속성(또는 프로젝트의 토큰 시스템)으로 작성하세요. 컴포넌트는 bg-indigo-500 또는 #6366f1과 같은 원시 값이 아닌 토큰 이름만 사용합니다.
• 구조는 두 번째. 시맨틱 HTML, 실제 링크(내비게이션용), 순서대로 제목, 그런 다음 스타일.
• 아래 빌드 시트와 references/visual-system.md 및 references/interaction.md의 세부 사항을 적용하세요.
• 모든 상태를 디자인하세요. 호버, 활성, focus-visible, 비활성화, 로딩, 빈 상태, 오류, 성공, 긴 콘텐츠 및 짧은 콘텐츠. 생성된 UI는 여기서 가장 약하며, 수정이 가장 저렴합니다.
• 스펙타클은 저렴하고 선택적으로 유지하세요. 무거운 효과(WebGL, 비디오, 큰 블러)는 브리핑 예산 내에서 하나의 격리된 레이어에 있으며, 첫 번째 페인트 후에 시작하고, 정적 폴백을 가지며, prefers-reduced-motion: no-preference 뒤에 위치합니다.

5. 비평 및 정리

첫 번째 빌드를 초안으로 취급하세요.

1. 스킬 자체 디렉토리의 스크립트 경로를 사용하여 정적 검사기를 실행하세요. Python 3.12 이상이 필요하며 패키지는 필요하지 않습니다. 변경한 파일뿐만 아니라 전체 프론트엔드 소스를 가리키세요: 포커스 및 reduced-motion 규칙은 스캔 범위 내 어디에서나 전역 스타일을 찾으므로 부분 스캔은 거짓 결함을 보고합니다.

   python <skill-dir>/scripts/check_slop.py <front-end source folder>
   

   모든 defect를 수정하세요(종료 코드 1은 적어도 하나가 남아 있음을 의미). 모든 tell에 대해 변경하거나 보고서에 왜 유지되는지 명시하세요. 검사기는 소스 텍스트만 읽으므로 깨끗한 결과는 필요 조건이지 충분 조건이 아닙니다.

2. 페이지를 렌더링하고 1440px 및 375px 너비에서, 두 가지 색상 구성표가 있다면 모두에서 살펴보세요. 세션에 브라우저 도구가 있다면 사용하세요. 그렇지 않으면 대부분의 머신에 헤드리스 Chrome 또는 Edge가 있습니다; 임시 폴더에 스크린샷과 브라우저 프로필을 작성한 다음 이미지를 읽으세요:

   chrome --headless=new --hide-scrollbars --user-data-dir=<temp>/profile --window-size=1440,2600 --virtual-time-budget=4000 --screenshot=<temp>/desktop.png <file or http URL>
   

   스크린샷은 전체 페이지가 아닌 주어진 크기의 단일 뷰포트이므로, 보려는 콘텐츠를 담을 수 있을 만큼 창을 충분히 높게 만드세요. Headless Chrome은 약 500px보다 좁은 창을 만들지 않으므로, 390px 스크린샷은 더 넓은 레이아웃에서 조용히 잘립니다. 자체 재생되는 조각은 루프의 임의 지점에서 캡처됩니다: 완성된 프레임을 위해 --force-prefers-reduced-motion을 추가하고, 루프 중간 프레임을 보기 위해 그것 없이 스크린샷을 하나 더 찍으세요. 휴대폰 확인을 위해, 사이트를 375px 너비의 <iframe>에 보관하는 작은 래퍼 페이지를 스크린샷하세요. 스크롤 시 나타나는 요소는 헤드리스 스크린샷에 나타나지 않을 수 있습니다. 숨겨진 시작 상태가 스크립트에 의해 적용되는지 소스에서 확인하세요(references/interaction.md 참조). 실제 브라우저 도구를 사용한다면, 모든 흐름을 탭 탐색하세요.

3. 추정하지 말고 페이지를 측정하세요. HTTP로 제공하고(정적 폴더의 경우, 해당 폴더에서 python -m http.server), 기본 모바일 프로필에서 Lighthouse를 실행한 다음 예산 판독기로 보고서를 읽으세요:

   npx [email protected] <http URL> --output=json --output-path=<temp>/report.json --quiet --chrome-flags="--headless=new --user-data-dir=<temp>/lh-profile"
   python <skill-dir>/scripts/check_budgets.py <temp>/report.json --script-kib <the brief's budget>
   

   LCP(2.5초), CLS(0.1), 총 차단 시간(200ms, INP의 실험실 대체), 브리핑 대비 스크립트 무게를 확인하고, 요소별로 모든 비합성 애니메이션을 나열합니다. 모든 breach를 수정하세요(종료 코드 1). 종료 코드 2는 수치가 측정되지 않음이거나 보고서를 사용할 수 없음을 의미합니다: 다시 실행하고, 여전히 실패하면 수치를 측정되지 않음으로 보고하고 통과된 것으로 보고하지 마세요. http.server는 압축하지 않으므로 스크립트 무게가 높게 읽히며, 이는 안전한 쪽으로 오류를 범합니다. Lighthouse가 Chrome을 찾을 수 없으면 CHROME_PATH를 설정하세요. Node 또는 네트워크를 사용할 수 없으면 보고서에 그렇게 명시하세요. Lighthouse는 시그니처 순간의 프레임 속도를 측정하지 않습니다. 세션에 브라우저 도구가 있다면 성능 추적을 기록하고, 그렇지 않으면 측정되지 않았다고 명시하세요.

4. 첫 화면이 눈에 볼 가치가 있는 것을 제공하는지 묻고, 히어로 조각에 references/artefacts.md의 충실도 체크리스트를 실행하세요. 정확하지만 잊혀지는 페이지는 소심한 시그니처를 가지고 있습니다: 더 많은 요소를 추가하기보다 시그니처를 강화하세요.

5. 페이지를 참조와 비교하세요. 선택한 방향에서 호평받는 사이트 하나, 해당 분야 디자이너가 존경할 만한 사이트 하나를 선택하고(references/exemplars.md에 몇 가지 이름이 있음), 2단계의 명령으로 1440px에서 첫 화면을 스크린샷하고 두 이미지를 나란히 보세요. 히어로 조각의 충실도, 가장 큰 유형과 가장 작은 세부 사항 사이의 범위, 신뢰할 수 있는 세부 사항의 양, 그리고 빛을 비교하세요. 가장 큰 격차를 찾아서 메우거나, 보고서에 왜 유지되는지 명시하세요. 참조는 외관이 아닌 장인 정신의 기준을 설정합니다. 표면에서 아무것도 가져오지 마세요. 사이트에 도달할 수 없으면 보고서에 그렇게 명시하세요.

6. references/interaction.md(상태, 포커스, 대상, 폼, 성능)의 체크리스트를 따르세요.

7. 브리핑이 아닌 구축된 페이지에 대해 references/slop-tells.md의 'AI 티' 확인을 다시 실행하세요. 검사기가 볼 수 없는 구조적 티(예: 중앙 배치된 배지 히어로, 세 개의 동일한 카드 및 전체적인 느낌 클러스터)를 다룹니다.

8. 주제나 사용자에게 도움이 되지 않는 모든 것을 제거하세요: 장식용 구분선, 자명한 콘텐츠 위의 레이블, 배지, 광선, 텍스트를 반복하는 아이콘, 두 번째 악센트 색상. 삭제는 일반적으로 가능한 가장 큰 개선입니다.

9. 브리핑, 비평이 변경한 사항, 참조 대비 가장 큰 격차, 예산 대비 측정된 수치, 그리고 확인할 수 없었던 모든 것(예: 브라우저 없이 렌더링된 대비)을 보고하세요.

빌드 시트

잘 출처가 밝혀진 시작 값. 좋은 결정을 보호합니다. 브리핑의 정체성 결정을 대체하지 않습니다.

차원(Dimension)	기본값(Default)
본문 텍스트	1620px, 줄 높이 약 1.5, 측정(measure) 4590자 (약 65자를 목표로)
제목	줄 높이 1.0~1.2, 24px 이상에서 자간 약 -0.02em, text-wrap: balance
단락	text-wrap: pretty; 굵게와 기울임은 함께 사용하지 않음
타입 스케일	clamp()를 통한 유동적, 작은 화면에서 약 1.2, 큰 화면에서 약 1.25 비율
모두 대문자	드물게, 한 줄 미만, 자간 0.05em~0.12em
색상	OKLCH; 하나의 색조를 띤 중성 스케일, 하나의 악센트, 서너 개의 의미 색상, 각각 역할 기반 단계 포함
대비	WCAG 4.5:1 본문, 3:1 큰 텍스트 및 UI 부품; 본문 텍스트에서 APCA Lc 75 이상 목표
다크 모드	별도의 팔레트: 어두운 회색 베이스(약 oklch(0.18 0.01 h)), 더 밝은 표면(높이를 위해), 채도 낮춘 악센트
그라디언트	in oklch로 보간; 인접한 색조; 선택적 미세 입자; 최대 하나의 의도적인 그라디언트
간격	4px 기준: 4, 8, 12, 16, 24, 32, 48, 64, 96, 128; 그룹 간 간격은 그룹 내 최소 두 배
깊이	톤 단계와 헤어라인 테두리가 우선; 그림자는 레이어드, 하나의 광원, 표면 색조로 착색
반경	두세 값; 중첩된 반경 = 외부 반경 - 패딩
아이콘	하나의 패밀리, 하나의 그리드, 하나의 획 두께

...

[skill.md 파일이 잘린 부분 이후의 내용은 원문을 그대로 유지하며, 위의 구조와 규칙에 따라 번역을 적용합니다. 전체 번역본은 상기 구조를 따릅니다.]