Communitygithub.com

WithZeng/design-skills

마케팅 사이트, 랜딩 페이지, 제품 홈페이지 또는 앱 UI 및 로그인/회원가입 페이지를 처음부터 끝까지 디자인하고 구축합니다. 사용자가 승인한 스크린샷과 이미지 생성 초안을 먼저 참조한 후, 통합 페이지 시스템, 브리프에서 파생된 아트 디렉션 및 모션 계획, 프로젝트에 맞는 컴포넌트 및 애니메이션 라이브러리, i18n, 접근성/e2e 검증을 적용합니다. 사용자가 공식 웹사이트, 랜딩 페이지, 홈페이지 또는 하위 페이지, 앱 화면(워크벤치, 채팅/에이전트 UI, 대시보드) 또는 인증 페이지를 디자인, 재디자인, 스타일 변경 또는 개선해 달라고 요청하거나, UI 참조 사이트를 요청하거나, 현재 디자인이 나쁘거나, 파편화되어 있거나, 모션이 부족하다고 말할 때 사용하세요.

design-skills란 무엇인가요?

이 스킬은 개발자와 AI 에이전트가 마케팅 사이트, 랜딩 페이지, 제품 홈페이지 또는 앱의 UI 및 인증 페이지를 전문적으로 디자인하고 구축할 수 있도록 안내하는 종합적인 워크플로우를 제공합니다. Scientify 사이트 재디자인(2026년 10월)에서 얻은 교훈을 바탕으로, 초안을 먼저 승인받고 하나의 페이지 시스템을 모든 섹션에 적용하며, 모션 라이브러리가 도입하는 대비 및 마크업 버그를 검증하는 것이 중요함을 강조합니다. 이 스킬은 Claude Code, Cursor, Codex와 같은 AI 코딩 도구에서 사용할 수 있도록 설계되었으며, 구체적인 게이트(승인 단계)를 통해 작업을 진행합니다. 주요 단계로는 브리프 수집(제품, 대상, 섹션, 샘플 데이터 및 참조 사이트), 코드 작성 전 승인을 위한 이미지 생성 초안 작성(전체 방향, 페이지 시스템, 섹션별 세부 사항, 인터랙션 스토리보드), 승인된 초안만 빌드(미리보기 경로 사용), 그리고 최종 검증(접근성, 대비, 모션 등)이 포함됩니다. 또한, 페이지 시스템(일관된 배경, 섹션 모듈, 타이포그래피, 아트 디렉션), 앱 UI 및 인증 페이지 스타일링, 아트 디렉션(차원 및 모션), 풍부한 인터랙션을 위한 라이브러리 선택 및 사용에 대한 상세한 지침을 제공합니다. 이 스킬은 디자인 작업의 품질과 일관성을 보장하고, 개발 프로세스를 체계화하여 효율적으로 전문가 수준의 결과물을 만들어내는 데 매우 유용합니다.

지원 대상~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/WithZeng/design-skills/tree/HEAD/skills/website-design

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

웹사이트 디자인

Scientify 사이트 재디자인(2026-10)에서 얻은 교훈: 초안을 보여주고 승인을 받은 후에야 디자인이 확정되었으며, 모든 섹션에 하나의 페이지 시스템이 적용되었고, 모션 라이브러리가 도입하는 대비 및 마크업 버그를 검증으로 잡아냈습니다.

워크플로우 및 게이트

  1. 브리프. 제품, 대상, 섹션, 실제 샘플 데이터, 사용자가 마음에 들어하는 참조 사이트 12개를 수집합니다. 사용자가 참조 사이트가 없으면, references/ui-references.md(갤러리, 실제 제품 UI 라이브러리, 컴포넌트 소스)에서 사이트 유형에 맞는 23개를 골라 승인을 위해 보여줍니다. 참조 사이트를 스크린샷으로 저장하여 --ref 이미지로 저장합니다. 추천을 요청받으면 번호가 매겨진 스크린샷과 선택할 수 있는 2~3개의 조합을 함께 보여줍니다(방법: ui-references, "참조 캡처").
  2. 초안은 코드보다 먼저. 사용자가 초안을 승인하기 전까지는 시각적 변경을 위해 코드를 절대 편집하지 않습니다. image-gen 스킬을 사용하세요. 순서:
    1. 방향이 정해지지 않은 경우, 방향당 하나의 개요 이미지(보통 2개)를 생성하며, 사용자는 세부 작업 전에 하나를 선택합니다. 그런 다음 페이지 시스템을 확정하기 위해 전체 페이지 긴 이미지 하나(1024x1536)를 생성합니다.
    2. 섹션/패널당 하나의 전체 해상도 상세 이미지.
    3. 하위 페이지, 그 다음 인터랙션 스토리보드(인터랙션당 3~4프레임)를 모션용으로 생성합니다. 각 배치를 보여주고, 피드백을 수집하며, 반복합니다. 프롬프트 템플릿: references/draft-prompts.md.
  3. 빌드는 승인된 초안만 수행하며, 사용자가 실시간 페이지를 대체하라고 말할 때까지 미리보기 경로 뒤에 둡니다. 패턴: references/build-patterns.md.
  4. 검증은 커밋/PR 전에 수행합니다: references/verification.md.
  5. 초안과 스크린샷은 프로젝트의 gitignored 스크래치 폴더(예: tmp/design/vN/)에 라운드별로 폴더를 만들어 저장하고, 프롬프트는 이미지 옆에 저장합니다.

페이지 시스템 ("割裂感"을 제거한 방법)

모든 섹션이 동일한 시스템을 재사용할 때 페이지는 하나의 조각처럼 느껴집니다. 승인된 초안에서 시스템의 값을 결정한 다음, 모든 프롬프트와 코드 토큰에 이를 작성하세요:

  • 전체 페이지에 대해 하나의 배경 처리 방식; 각 섹션이 자체적인 밴드나 그라데이션을 만들어내는 것을 피하세요.
  • 하나의 섹션 모듈(컨테이너, 반경, 채우기, 테두리, 패딩, 너비)과 그 안에 사용할 소수의 레이아웃 세트를 정하고 섹션마다 재사용합니다.
  • 하나의 타이포그래피 스케일: 모든 섹션 제목에 동일한 크기와 굵기, 하나의 본문 스타일, 일관된 간격.
  • 하나의 시그니처 요소가 아트 디렉션을 전달합니다(보통 히어로 영역); 나머지 요소는 레이아웃에서 조용하게 유지되지만 인터랙션에는 반응합니다. 이 요소는 템플릿이 아닌 브리프에서 결정됩니다: 아래 "아트 디렉션" 참조.
  • 표시되는 모든 제품 UI는 동일한 앱(동일한 내비게이션, 테마, 데이터)이어야 페이지가 하나의 제품으로 읽힙니다.
  • 시스템을 일관되게 유지할 수 있을 정도로 제한된 팔레트(한 사이트는 순수 모노크롬을 사용했습니다); 로고는 원래 색상을 유지합니다. 실제 브랜드 로고를 항상 사용하고, 절대 사각형 안에 글자를 넣은 플레이스홀더를 사용하지 마세요.
  • 콘텐츠: 제품 도메인의 현실적인 데이터(그럴듯한 이름, 숫자 및 타이밍)와 프로젝트별로 결정된 파일 및 객체의 일관된 명명 규칙을 사용합니다. 로렘 입숨, 가짜 사용 후기 또는 통계, 유행어 슬로건은 사용하지 마세요.

앱 UI 및 인증 페이지

동일한 게이트가 제품 내부에도 적용되지만, 다른 참조와 토큰을 사용합니다:

  • 참조는 실제 제품 UI(예: Refero, 경쟁 제품 사이트의 제품 스크린샷, 채팅/에이전트 화면용 컴포넌트 문서)에서 가져오며, 랜딩 페이지 갤러리는 사용하지 않습니다.
  • 앱 자체의 토큰과 컴포넌트를 재사용하고, 마케팅 사이트의 팔레트를 가져오지 마세요. 먼저 소수의 공유 프리미티브(패널, 페이지 컨테이너 너비, 대화상자 너비, 분할 컨트롤)를 고정한 다음, 이를 사용하여 화면의 스타일을 변경합니다.
  • 호스팅된 인증 위젯(예: Clerk)을 사용한 로그인/회원가입: 외관 API와 현지화를 통해 스타일을 지정하고, build-patterns("인증 페이지")의 함정을 확인하세요.

아트 디렉션 (차원과 모션)

입체적이고 움직이는 부분을 사이트 자체의 요구 사항에서 디자인한 다음, 다른 시각적 요소와 마찬가지로 초안을 작성하세요. 이전 사이트의 레시피나 고정된 값을 재사용하지 마세요.

  1. 브리프에서 파생. 방문자가 반드시 얻어야 할 한 가지 아이디어(실제 제품, 변화, 규모, 정밀성, 평온함)는 무엇인가요? 대상은 누구이며, 브랜드 톤은 무엇이며, 어떤 기기와 성능 예산이 있나요? 시그니처 요소는 그 아이디어를 보여주어야 하며, 이상적으로는 실제 제품을 사용합니다.
  2. 2~3가지 옵션 탐색 페이지 시스템과 톤에 맞는 옵션(예: 원근감의 제품 창, 시차 효과가 있는 레이어드 깊이, 워크플로우를 설명하는 스크롤 기반 장면, 일러스트레이션이나 3D 객체, 데이터/시각적 은유, 또는 풍부한 마이크로 인터랙션이 있는 평온한 평면 페이지)을 탐색합니다. 각 옵션을 이미지로 초안을 작성하고, 모션의 경우 스토리보드로 작성합니다. 사용자가 선택합니다.
  3. 명세화 후 빌드. 선택된 옵션에 대해 다음을 기록합니다: 무엇이 움직이는지, 무엇이 트리거하는지(로드, 스크롤, 포인터, 시간, 클릭), 정지 상태, 모션 감소 버전, 모바일 버전. 각도, 타이밍 및 강도를 템플릿이 아닌 브라우저에서 승인된 초안과 비교하여 조정합니다.
  4. 비용 확인. 가독성, 대비, 레이아웃 안정성 또는 로드 시간을 해치지 않아야 하며, JS 없이도 우아하게 저하되어야 하고 모션 감소 설정에서도 문제가 없어야 합니다.

풍부한 인터랙션, 라이브러리 활용

정적인 페이지는 싸구려처럼 보입니다. 컴포넌트 및 애니메이션 라이브러리를 적극적으로 사용하여 모든 인터랙션이 살아있도록 만드세요:

  • 모든 상태는 피드백을 받습니다: 호버, 누름, 포커스, 로딩/실행 중, 성공/실패, 나타남/사라짐, 레이아웃 변경. 이러한 피드백을 인터랙션 스토리보드에서 계획하고, 나중에 추가하는 방식으로 하지 마세요.
  • 직접 손으로 작성한 효과보다 잘 만들어진 기성 컴포넌트를 선호하세요. 각 인터랙션을 패턴에 매핑한 다음, 이 프로젝트를 위해 선택된 라이브러리(references/ui-references.md, "인터랙션 패턴")에서 컴포넌트를 선택하세요.
  • 제품 데모는 움직여야 합니다: 실제 작업이 진행되고, 결과가 도착하고, 숫자가 변하고, 장면이 전환됩니다.
  • 목적을 가지고 사용하세요: 모션은 상태를 설명하거나 변경된 부분으로 시선을 끕니다. 과도한 장식 효과는 작업 화면이 아닌 마케팅 페이지에 속합니다. 모든 곳에서 모션 감소 설정을 존중하세요.

라이브러리 선택

프로젝트에 맞는 컴포넌트 및 애니메이션 라이브러리를 선택하세요. 필수는 아닙니다.

  • 기존 프로젝트: 이미 있는 것을 사용하세요. 갭이 있을 때만 라이브러리를 추가하고, 기존 라이브러리와 중복되는 라이브러리는 절대 추가하지 마세요.
  • 새 프로젝트: 프로젝트 유형, 프레임워크 및 요구 사항에 따라 선택하세요(기준 및 후보는 references/build-patterns.md, "라이브러리 선택" 참조). 명확한 이유가 없는 한, 하나의 기본 컴포넌트 시스템과 하나의 주요 애니메이션 라이브러리를 유지하세요.
  • 불투명한 패키지보다는 편집 가능한 소스로 프로젝트에 설치(레지스트리/CLI 또는 복사)할 수 있는 소스를 선호하여 컴포넌트가 프로젝트의 토큰을 따르도록 하세요.

힘들게 얻은 규칙 (자세한 내용은 build-patterns 참조)

  • 모든 텍스트 색조는 배경이 되는 표면에서 4.5:1 대비를 통과해야 합니다. 페이지 배경뿐만 아니라 패널 채우기에서 가장 희미한 토큰도 확인하세요.
  • 접힌 부분 위로 나타나는 요소에 불투명도 페이드 인을 사용하지 말고, "비활성" 상태에 불투명도 디밍을 사용하지 마세요 — axe 감사는 애니메이션 중에 이를 감지하고 대비를 지적합니다. 변환만 사용하는 등장과 색상 변경을 사용하세요.
  • 애니메이션 래퍼는 <ul>/<ol>과 <li> 사이에 위치하면 안 됩니다. <li> 내부에서 애니메이션을 적용하세요.
  • 슬라이딩 필: 라벨을 절대 위치의 필 위에 있는 relative span에 배치하세요. -z-10 + isolate을 사용하지 마세요.
  • 카운터는 서버에서 최종 값을 렌더링하고 뷰포트에 들어왔을 때만 애니메이션을 적용합니다.
  • 다국어 사이트에서 모든 표시 문자열은 i18n을 거쳐야 하며, 모의 창과 재생된 세션 내부의 데모 UI도 포함됩니다.
  • 그리드는 명시적인 단일 열 / minmax(0,1fr) 트랙이 필요하고, 페이지 루트는 모바일 오버플로를 방지하기 위해 가로 오버플로를 자릅니다.

관련 스킬