랜딩 페이지 디렉터

랜딩 페이지 디렉터은(는) 무엇을 하나요?

자유로운 스타일링 대신 명시적인 디자인 결정을 통해 랜딩 페이지를 제작합니다. 품질은 순서에서 비롯됩니다: 브리프를 이해하고, 시각적 방향을 좁히고, 시스템을 고정하고, 레퍼런스를 만들고, 충실하게 번역하고, 렌더링된 결과를 검사합니다.

이 스킬은 랜딩 페이지 워크플로우를 소유합니다. 지원하는 이미지, 번역, 테스트, 브랜드, 카피 또는 프레임워크 스킬이 전문 작업을 기여할 수 있지만, 이 워크플로우를 대체하거나 두 번째 경쟁 아트 디렉션을 도입해서는 안 됩니다.

기본 실행

아트 디렉션과 완전한 빌드/리뷰 루프에 이 디렉터를 사용하십시오. design-harness가 설치 및 구성된 경우, 격리된 구현, 저장된 컨텍스트, 브라우저 증거 및 제한된 수정을 위해 로드하십시오. 그렇지 않으면 이러한 단계를 직접 수행하고 기록하십시오. 실행 가능한 하네스 검사가 실행되었다고 주장하지 마십시오. 사용자가 두 번째 스킬을 호출할 필요는 없습니다. 단일 단계를 할당받은 하위 스킬은 다른 오케스트레이션 루프를 시작하지 않고 상위 스킬로 돌아가야 합니다.

호환성

시각적 레퍼런스를 위해 내장 이미지 생성을 사용하고 최종 시각적 QA를 위해 브라우저 검사 도구를 사용하십시오. imagegen-frontend-web, image-to-code, brand-consistency 및 playwright-visual-testing이 가능할 때 조정하십시오. 전체 랜딩 페이지 빌드 및 대규모 재디자인에는 GSAP 안무를 기본으로 사용하고 로컬 상호작용 피드백에는 CSS를 사용하십시오. 명시적인 정적 요청, 보존 제약 조건 및 기존 필수 모션 시스템을 존중하십시오.

핵심 계약

• 승인된 카피, 사실적 주장, 로고, 브랜드 자산, 페이지 순서 및 소스 템플릿 요구 사항을 고정된 것으로 취급하십시오.
• 클라이언트 웹사이트, 콘텐츠 소스, 브랜드 가이드, 로고, 글꼴, 제공된 미디어, 제품 비주얼 및 관련 레퍼런스를 아직 사용할 수 없을 때 요청하십시오. 첫 번째 메시지에 첨부된 것이 없어도 소스 자료가 존재하지 않는다고 가정하지 마십시오.
• 아트 디렉션을 제안하기 전에 제공된 모든 문서, URL, 이미지, 브랜드 파일 및 리포지토리 소스를 읽고 인벤토리로 만드십시오.
• 통계, 사용후기, 수상 내역, 클라이언트, 인증, 위치, 연락처 정보, 제품 스크린샷 또는 증거를 절대 만들어 내지 마십시오.
• 누락된 정보는 안전하게 생략할 수 없을 때 [확인 필요]로 표시하십시오.
• 구현 전에 하나의 일관된 시각적 언어를 확립하십시오.
• 사용자가 시각적 승인 체크포인트를 요청하지 않는 한 일상적인 아트 디렉션 및 레퍼런스 선택 결정을 소유하십시오. 에이전트가 선택한 레퍼런스를 정직하게 기록하고, 사용자 승인을 받았다고 부르지 마십시오. 일반적인 디자인 선택이 아닌 콘텐츠 불확실성 및 고정된 요구 사항과의 충돌을 에스컬레이션하십시오.
• 제어되고 읽기 쉬운 계층 구조를 화려함보다 선호하십시오: 프리미엄 결과는 거대한 타이포그래피, 혼잡한 히어로, 장식적 표식 또는 과도한 브랜딩에 의존해서는 안 됩니다.
• 모션을 시각적 언어의 일부로 취급하십시오: 목적, 성격, 타이밍 시스템 및 축소 모션 대응을 제공하십시오.
• 정확히 하나의 기본 취향 방향을 사용하십시오. 여러 스타일 스킬이나 무드보드를 혼합하지 마십시오.
• 시각적 품질이 핵심일 때 코딩 전에 시각적 레퍼런스를 생성하고 비판적으로 검토하십시오.
• 실제로 작동하는 페이지를 구축하고, 정적인 모형처럼 보이는 더미 컨트롤을 만들지 마십시오.
• 완료를 보고하기 전에 실제 렌더링된 페이지를 데스크탑 및 모바일 너비에서 검사하십시오.

워크플로우 상태 머신

단계를 순서대로 따르십시오. 사용자가 해당 단계에서 설정할 모든 것을 이미 제공한 경우에만 단계를 건너뛰십시오. 사용자에게 브리프, 파일, 대화, 브랜드 키트 또는 레퍼런스 URL에 이미 있는 정보를 반복하도록 요청하지 마십시오.

1. 브리프 읽기 및 분류

사용자에게 무엇이든 요청하기 전에 대화 및 작업 공간에 이미 있는 모든 것을 인벤토리로 만드십시오. references/guided-intake.md를 읽고 소스 세트가 누락되었거나 불완전할 때 소스 자료 사전 점검을 실행하십시오.

소스 인벤토리는 다음을 포함합니다:

• 클라이언트 이름, 현재 웹사이트 또는 소스 페이지 URL, 그리고 작업이 새 페이지, 재디자인, 복제 또는 확장인지 여부
• 승인된 콘텐츠 문서, 카피 상태, 필수 페이지/섹션 순서, 주장, 법적 텍스트 및 기본 전환
• 브랜드 가이드, 로고, 마크, 색상 사양, 글꼴 파일 및 라이선스, 아이콘 시스템 및 이전 콜래터럴
• 제공된 사진, 비디오, 일러스트레이션, 다이어그램, 제품 스크린샷, UI 캡처, 사용후기, 증거 및 규정 준수 자료
• 클라이언트가 좋아하고 싫어하는 것을 포함한 경쟁사 또는 영감 레퍼런스
• 기존 리포지토리, 프레임워크, 컴포넌트 시스템, 기술적 제약 조건, 분석/양식 대상 및 배포 기대 사항

아무 것도 없으면, 프로젝트가 그린필드임을 기록하고 자산이 제공된 척하지 않고 진행하십시오. 사용자가 웹사이트, 문서, 폴더 또는 자산 세트가 존재하지만 접근할 수 없다고 표시하면, 이에 의존하는 결정을 내리기 전에 URL, 첨부 파일, 경로 또는 권한을 요청하십시오.

작업을 분류하십시오:

• 새롭고 시각적으로 정의되지 않음: 안내된 인테이크 및 방향 선택을 실행하십시오.
• 명시적인 시각적 브리프가 있는 새 작업: 컴파일된 브리프를 확인하고 레퍼런스로 진행하십시오.
• 레퍼런스 주도 또는 복제: 레퍼런스를 분석하고 요청된 구조, 콘텐츠 및 상호작용 모델을 보존하십시오.
• 재디자인: 방향을 제안하기 전에 현재 페이지를 감사하십시오. 작동하는 기능과 고정된 카피를 보존하십시오.

코드를 변경하기 전에 리포지토리 및 그 명령 파일을 검사하십시오. 사용자가 명시적으로 마이그레이션을 요청하지 않는 한 기존 프레임워크, 패키지 관리자, 컴포넌트 규칙 및 런타임을 보존하십시오.

2. 필요할 때 안내된 인테이크 실행

디자인 결정이 위임된 경우, 클라이언트 컨텍스트에서 해결되지 않은 시각적 선호도를 선택하고 인터뷰를 실행하는 대신 추론을 기록하십시오. 사용자가 협력적인 방향 선택을 원하거나 자료 요구 사항을 안전하게 추론할 수 없을 때만 아래 질문을 사용하십시오.

소스 자료 사전 점검은 디자인 질문 전에 이루어지며 디자인 질문 제한에 포함되지 않습니다. 대화, 작업 공간, 현재 웹사이트 또는 연결된 소스에서 이미 찾은 자료에 대해 묻지 마십시오.

한 번에 하나의 결정을 물으십시오. 각 질문에는 두세 개의 상호 배타적인 선택이 포함되어야 하며, 권장 선택을 먼저 배치하고 한 문장으로 시각적 또는 상업적 효과를 설명하고 자유로운 대안을 허용해야 합니다. "방향 1/4"와 같은 진행 상황을 계속 표시하십시오.

해결되지 않은 결정만 우선시하십시오. 일반적인 모호한 브리프에는 네 가지 결정이 필요합니다:

1. 시각적 방향
2. 색상 분위기
3. 타이포그래피 특성
4. 히어로/레이아웃 구조

브리프가 추론 가능하게 만들지 않는 경우에만 이미지, 모션 또는 전환 아키텍처에 대해 물으십시오. 모션이 상업적 또는 내러티브적으로 중요할 때, 경험이 절제된, 표현적인 또는 스크롤 주도인지 느껴야 하는지 물어보고 성능 트레이드오프를 설명하십시오. 사용자가 더 깊은 워크숍을 요청하지 않는 한 인터뷰를 6개 질문 이하로 유지하십시오.

자료 방향 선택이 해결되지 않은 상태에서 코딩을 시작하지 마십시오.

3. 세 가지 명명된 방향 제시

정의되지 않은 브랜드 방향의 경우, 동일한 레이아웃의 세 가지 색상 변형이 아닌 진정으로 다른 세 가지 경로를 제안하십시오. 각 방향은 다음을 지정해야 합니다:

• 기억에 남는 이름
• 전략적 아이디어 및 대상 인상
• 글꼴 페어링 또는 타이포그래피 범주
• 대표적인 색상 역할이 있는 팔레트 분위기
• 히어로 구성
• 히어로 밀도, 헤드라인 크기 범위, 첫 번째 뷰포트 콘텐츠 예산 및 폴드 아래에 의도적으로 연기된 것
• 이미지 처리
• 내비게이션 및 푸터의 로고 처리(배경 처리 및 최대 시각적 공간 포함)
• 표면, 테두리, 반경 및 그림자 특성
• CTA 처리 및 기본 전환이 장식적 혼란 없이 시각적으로 지배적이 되는 방법
• 모션 특성
• 주요 트레이드오프

디자인이 위임된 경우, 경로를 간략히 비교하고 가장 강력한 것을 선택하고 그 히어로 레퍼런스를 생성하십시오. 그렇지 않으면 한 경로를 권장하고 요청된 협력 체크포인트를 위해 대안을 제시하십시오. 하나의 선택된 경로가 작업을 해결할 수 있을 때 세 가지 완전한 방향을 생성하지 마십시오.

4. 디자인 브리프 컴파일 및 고정

references/design-brief-schema.md를 읽으십시오. 해당 구조를 사용하여 프로젝트 내에 DESIGN-BRIEF.md를 작성하십시오.

references/visual-calibration.md를 읽어 구체적인 시각적 목표와 수정 루프를 확립하십시오. 이는 브리프가 "프리미엄", "현대적인" 또는 "더 좋게 만들어 줘"라고만 말할 때 특히 중요합니다.

선택을 구현 준비 규칙으로 번역하십시오: 명명된 글꼴, 두께, 타입 스케일, 색상 토큰, 그리드, 최대 너비, 간격 리듬, 반경, 테두리, 그림자, 이미지 규칙, 섹션 리듬, 상호작용, 모션 토큰, 모션 감소 및 중단점 변환.

또한 일반적으로 후기 단계에서 거부를 유발하는 실용적인 구성 제약 조건을 고정하십시오:

• 데스크탑 및 모바일에서 최대 히어로 헤드라인 너비 및 크기
• 첫 번째 뷰포트 우선 순서 및 텍스트, 미디어, 증거 및 작업에 대한 밀도 예산
• 헤더 높이 및 최대 로고 높이와 너비; 마크가 배경 없이 앉아야 할 때 진정한 투명 자산 사용
• 규모, 대비, 배치 및 지원 컨텍스트를 통한 기본 CTA 두드러짐
• 인덱스, 구분선, 테두리, 아이콘 및 텍스트 사이의 최소 간격
• 증거, 성공, 프로세스 및 전환 섹션이 동일한 카드 그리드의 변형이 되지 않도록 하는 섹션별 구성 규칙
• 명시적으로 승인된 처리, 싫어하는 처리 및 페이지에서 나중에 다시 나타나지 않아야 하는 거부된 모티프

세 가지 종류의 정보를 분리하십시오:

• 고정됨: 승인된 카피, 브랜드 사실, 제공된 자산, 선택된 방향.
• 파생됨: 디자인 토큰, 반응형 동작, 구성 규칙.
• 해결되지 않음: 아직 확인을 기다리는 정보.

이 스킬의 번들 스크립트에 접근할 수 있을 때 node scripts/validate_design_brief.mjs <project>/DESIGN-BRIEF.md를 실행하십시오. 계속하기 전에 누락되거나 플레이스홀더 섹션을 수정하십시오.

5. 이미지 우선 섹션 레퍼런스 생성

imagegen-frontend-web을 로드한 다음 내장 이미지 생성 기능을 사용하십시오.

페이지의 내러티브를 계획하십시오. 먼저 히어로 레퍼런스를 생성하고 비판적으로 검토하여 약한 구성을 수정한 다음 다른 섹션으로 확장하십시오. 계획된 각 섹션에 대해 하나의 별도 대형 가로 레퍼런스 이미지를 생성하십시오. 7개 섹션이 있는 페이지는 7개의 섹션 이미지를 받습니다. 전체 페이지 합성물에서 작은 조각을 자르는 대신 새로운 디테일 레퍼런스를 생성하십시오.

모든 레퍼런스에서 다음을 일정하게 유지하십시오:

• 팔레트 및 색상 역할
• 글꼴 페어링 및 타이포그래피 성격
• 그리드 로직 및 간격 리듬
• 테두리, 반경, 아이콘 및 표면 언어
• 이미지 처리 및 아트 디렉션

섹션 구성을 의도적으로 다양하게 하십시오. 왼쪽 텍스트/오른쪽 이미지, 카드 그리드, 벤토 컨테이너 및 과도하게 큰 중앙 헤드라인을 기본적으로 반복하지 마십시오.

프로젝트 바운드 레퍼런스를 design-references/ 아래에 01-hero.png, 02-proof.png, 03-product.png와 같은 순서 이름으로 저장하십시오. 승인된 레퍼런스를 시각적 진실의 소스로 취급하십시오.

격리된 보드뿐만 아니라 현실적인 뷰포트 크롭에서 레퍼런스를 검토하십시오. 구현 전에 다음을 확인하십시오:

• 히어로에는 하나의 지배적인 메시지, 하나의 지배적인 행동이 있으며 증거, 이미지, 레이블 또는 장식 장치의 경쟁 클러스터가 없습니다.
• 디스플레이 타입은 캔버스에 비해 과도하게 크지 않고 정상적인 보기 크기에서 자신감 있게 느껴집니다.
• 헤더 로고는 내비게이션에 시각적으로 종속되며 우발적인 흰색 사각형이나 일치하지 않는 배경을 도입하지 않습니다.
• 최종 전환 섹션은 단순히 중앙에 배치된 카피와 버튼이 아닌 충분한 대비와 시각적 무게를 가진 디자인된 순간입니다.
• 번호가 매겨진 행, 타임라인 단계 및 규칙 목록은 줄의 양쪽에 숨 쉴 공간이 있습니다.
• 장식 기호가 구성이나 의미의 대체물로 사용되지 않습니다.

방향 선택과 레퍼런스 검토는 별도의 체크포인트입니다. 명명된 경로가 그 실행이 좋다는 것을 확립하지는 않습니다. 사용자가 레퍼런스를 거부하면 수정하십시오. 거부된 구성에서 코딩을 시작하지 마십시오.

정적 이미지는 타이밍을 완전히 지정할 수 없습니다. 이동하는 각 섹션에 대해 디자인 브리프에 간결한 모션 주석을 추가하십시오: 트리거, 시퀀스, 공간 변화, 지속 시간, 이징, 반복, 모바일 적응 및 축소 모션 결과. 레퍼런스에 깊이 또는 레이어 이미지가 포함되어 있다고 해서 단순히 애니메이션을 발명하지 마십시오.

사용자가 시각적 승인을 요청한 경우, 레퍼런스를 보여주고 그 체크포인트에서 기다리십시오. 그렇지 않으면 비판적 검토 후 레퍼런스를 선택하고 자율적으로 계속하십시오. 이 워크플로우에서 에이전트가 수락한 레퍼런스는 구현 진실의 소스 역할을 할 수 있지만 사용자가 승인한 것으로 설명되어서는 안 됩니다.

6. 레퍼런스를 코드로 번역

image-to-code를 로드하고 승인된 모든 레퍼런스를 타이포그래피, 간격, 색상, 구성, 이미지, 컴포넌트, 반응형 의도 및 상호작용 신호에 대해 분석하십시오.

섹션을 구성하기 전에 다음에 대한 시맨틱 토큰을 구현하십시오:

• 배경, 전경, 희미한 텍스트, 악센트, 테두리 및 표면 색상
• 디스플레이 및 본문 글꼴 패밀리
• 타입 스케일 및 줄 높이 관계
• 간격 리듬 및 콘텐츠 너비
• 반경, 테두리 및 그림자 레벨
• 모션 지속 시간 및 이징

헤더와 히어로를 첫 번째 시각적 조각으로 구현하고 나머지 섹션을 번역하기 전에 1440픽셀과 390픽셀에서 검사하십시오. 로고 크기와 배경, 히어로 밀도, 헤드라인 줄 바꿈, CTA 무게 및 폴드 구성을 이 시점에서 수정하여 약한 첫 화면이 페이지를 통해 전파되지 않도록 하십시오.

가능할 때 로고에 대해 본질적인 투명 이미지 자산을 사용하십시오. CSS 블렌딩, 흰색 컨테이너, 클리핑 또는 필터는 원하지 않는 내장 배경을 제거하기 위한 대체물이 아닙니다. 로고는 소스 비트맵 치수뿐만 아니라 보이는 마크로 크기를 조정하십시오.

규칙 또는 번호가 매겨진 컴포넌트에서 숫자와 구분선 또는 콘텐츠 가장자리 사이에 명시적인 간격을 예약하십시오. 렌더링된 결과에서 광학적 여유를 확인하십시오. 수학적으로 동일한 패딩도 얇은 규칙 근처에서 비좁게 보일 수 있습니다.

시맨틱하고 접근 가능한 HTML을 구축하십시오.

…

[번역을 위해 잘림]