Design Handoff (디자인 핸드오프)

Design Handoff (디자인 핸드오프)은(는) 무엇을 하나요?

카피가 승인되었습니다. 디자이너나 와이어프레임 생성기가 카피에서 필요로 하는 것은 단어 자체가 아닙니다. 각 단어 블록이 독자에게 어떤 영향을 미쳐야 하는지, 어떤 순서로, 그리고 그 중 어떤 것이 모바일 환경에서도 유지되어야 하는지입니다. 이 스킬은 하나를 다른 것으로 바꾸며, 카피가 이미 결정한 사항에 대해서는 아무것도 결정하지 않습니다.

게이트: 승인된 카피, 그리고 섹션별 섹션 사양

두 가지 입력이 필요합니다. 두 번째 입력이 자주 누락됩니다.

승인된 카피, 초안이 아닌 것. 아직 논쟁 중인 단락을 중심으로 구축된 레이아웃은 재구축되며, 재구축은 항상 더 나빠집니다. 그 시점에서는 다른 단어를 위해 선택된 형태에 패치를 적용하는 것이기 때문입니다. 카피가 아직 확정되지 않았다면 중단하고 그렇게 말하십시오.

섹션별 섹션 사양. ../conversion-page-build/SKILL.md는 ## The section spec 헤딩 아래에 카피와 함께 하나의 사양을 생성합니다. 이 스킬은 다음 5개의 키 이름으로만 해당 사양을 읽습니다: section_type, purpose, content_hierarchy, components, responsive_intent. 해당 파일이 사양의 형태와 카피 이후에 작성되어야 하는 이유를 정의합니다.

사양 없이 도착한 카피도 여전히 핸드오프될 수 있습니다. 먼저 카피로부터 사양을 작성하고, 출력물에 'inferred'(추론됨)로 표시하십시오. 완성된 카피에서 역설계된 사양은 카피가 하려는 것으로 보이는 일을 기록하지만, 이는 카피가 원래 의도한 것과 동일하지 않습니다. 이 둘이 다른 경우, 디자이너는 의도와 다른 내용을 충실히 레이아웃하게 되고, 다운스트림에서 이를 잡아낼 수 없습니다.

순서

네 단계로 구성됩니다. 처음 세 단계는 항상 실행됩니다. 네 번째 단계는 일반적으로 실행되지 않습니다.

1. 각 섹션 사양을 컴포넌트에 매핑 - references/section-to-component.md. 다섯 개의 키를 섹션별 컴포넌트 목록으로 변환하고, 해당 섹션의 레이아웃을 제약하는 한 가지 사항을 추가합니다.
2. 와이어프레임 브리프 작성 - references/relume-brief.md. 페이지 수준의 프레이밍 후, 섹션별로 하나의 블록: 구조와 콘텐츠 기능, 외형은 없음.
3. 리파인먼트 스펙 작성 - references/figma-refinement-spec.md. 시각적 계층 구조, 강조, 접힌 부분 위 우선순위, 스캔 경로: 와이어프레임이 결정하지 못하는 네 가지 사항.
4. 플랫폼 노트, 조건부 - 아래 참조.

2단계와 3단계는 의도적으로 별도의 문서로 유지되며, 그 순서도 유지됩니다. 그 이유는 references/figma-refinement-spec.md의 도입부에 명시되어 있으며 여기서 반복하지 않습니다.

플랫폼 패스는 플랫폼이 명명된 경우에만 실행됩니다

빌드 대상이 명명되고 그것이 WordPress인 경우가 아니라면 references/platform-notes-wordpress.md를 열지 마십시오. Webflow 빌드, Framer 빌드, 수동 코딩 빌드, 그리고 명명되지 않은 빌드는 모두 여기서 아무것도 로드하지 않습니다.

이것은 단순한 파일 정리가 아닙니다. 플랫폼 노트는 한 플랫폼에서는 실제이고 다른 플랫폼에서는 거짓인 제약 조건을 설명합니다. 따라서 적용되지 않는 제약 조건을 포함하는 스펙은 디자이너로 하여금 존재하지 않는 문제를 해결하게 만들고, 누군가가 그 해결책에 의문을 제기할 때 그것을 방어하게 만듭니다. 잘못된 노트는 노트가 없는 것보다 더 큰 비용을 초래합니다.

대상이 명명되지 않은 경우 물어보십시오. 답변이 "아직 결정되지 않음"이라면, 플랫폼 없는 핸드오프를 작성하고 출력에 플랫폼 패스가 실행되지 않았음을 기록하여, 빌드를 인계받는 사람이 패스가 통과되었다고 가정하지 않고 확인해야 할 사항이 있음을 알 수 있도록 하십시오.

모든 플랫폼 파일은 동일한 형태를 가지며 그 외의 것은 포함하지 않습니다: 동작당 하나의 노트로, 각 노트는 세 가지 사항을 명시합니다 - 플랫폼 동작, 해당 동작으로 인해 발생하는 실패, 그리고 이를 방지하는 표현. 이 스킬에 해당 플랫폼에 대한 파일이 없으면 노트를 생성하지 않습니다. WordPress 노트를 기본값으로 사용하지 마십시오. 이것이 조건문이 방지하려는 특정 실수입니다.

도구 이름은 문에 있을 뿐, 방법론에 있는 것이 아닙니다

두 참조 파일은 도구 이름을 따서 명명되었습니다( references/relume-brief.md 및 references/figma-refinement-spec.md ). 이는 사람들이 그 이름으로 요청하기 때문입니다. 둘 중 어느 것도 도구에 의존하지 않으며, 어느 것도 어떤 도구가 주어진 입력으로 무엇을 하는지에 대해 주장하지 않습니다.

이러한 제약은 의도적입니다. "도구 X는 이렇게 생긴 설명을 받아들입니다"라고 말하는 스킬은 다른 사람의 제품에 대한 주장을 하는 것이며, 이는 조용히 시대에 뒤쳐집니다. 독자는 현재의 주장과 2년 된 주장을 구별할 방법이 없습니다. 따라서 이 파일들은 문서가 무엇을 포함하고 왜 그렇게 구성되었는지를 설명합니다. 도구에 대한 어떤 것이 실제로 확인된 경우, 파일은 확인된 날짜와 함께 그 내용을 명시하며, 확인 범위를 넘어서는 어떤 것도 말하지 않습니다.

레지스터는 정확히 한 곳에서 디자인에 도달합니다

레지스터는 Conversion Brief에서 상속되며 여기서 다시 결정되지 않습니다. 그 이유는 ../audience-research/SKILL.md에 속합니다. 다섯 가지 프로필 자체는 ../audience-research/references/register-profiles.md에 있습니다.

레지스터는 이 스킬에서 한 가지 결정에 영향을 미칩니다: 페이지가 사용할 수 있는 강조(emphasis)의 양. 여기의 다른 모든 것은 구조적이며 변경되지 않고 전달됩니다. 동일한 섹션은 독자가 누구든 동일한 작업을 수행해야 합니다. references/figma-refinement-spec.md가 그 하나의 교차점을 처리하며, 이 스킬에서 레지스터 행을 읽는 유일한 파일입니다.

이 스킬이 하지 않는 일

• 카피를 다시 쓰지 않습니다. 섹션을 레이아웃할 수 없는 이유가 카피가 해당 섹션의 용도를 전혀 명시하지 않기 때문이라면, 문제가 표현(phrasing)일 경우 ../copy-sweeps/SKILL.md를, 문제가 누락된 인수(missing argument)일 경우 ../conversion-page-build/SKILL.md를 확인하십시오. 어느 것인지 지정하고 중단하십시오.
• 시각적 스타일을 선택하지 않습니다. 색상 팔레트, 타입 스케일, 간격 값, 중단점 숫자가 없습니다. 순위와 관계를 설정합니다; 디자인 시스템이 값을 제공합니다. references/figma-refinement-spec.md는 이 거부를 자세히 명시하고, 값을 제공할 디자인 시스템이 없을 때 어떻게 해야 하는지 설명합니다.
• 이미 출시된 페이지에서 작업하지 않습니다. 이 스킬은 승인된 카피에서 아직 구축되지 않은 레이아웃 방향으로 실행됩니다. 기존 레이아웃을 평가하는 것은 반대 방향으로 실행되며, 이 스킬이 가지고 있지 않은 증거가 필요합니다 - ../conversion-page-audit/SKILL.md.
• 빌드하지 않습니다. 플랫폼 노트는 스펙이 빌드 대상이 저렴하게 수행할 수 없는 것을 요구하지 않도록 존재합니다. 이는 빌드 지침이 아니며, 이 스킬을 빌드 스킬로 만들지 않습니다.

미해결 항목

핸드오프가 카피와 브리프만으로 해결할 수 없는 모든 것은 문서에 NOT ESTABLISHED — <해결 방법> 형식으로 기록되고 추측하지 않습니다. 이 원칙과 그 근거는 전체 플러그인에 대해 ../audience-research/SKILL.md에 한 번 명시되어 있으며, 여기에 변경 없이 적용됩니다. 가장 흔히 발생하는 두 가지 사례는: 레이아웃이 의존하지만 아직 제작되지 않은 에셋, 그리고 카피가 약속했지만 존재하지 않는 증거 요소입니다.

산출물

단일 핸드오프 문서입니다. 이 볼트(vault)의 파일링 규칙에 따라 03 Projects/<Project>/<Page>/[C] Design Handoff — <Page>.md에 위치합니다; 다른 곳에서는 프로젝트가 사양을 보관하는 곳 어디든지 저장됩니다. 다음 순서로 포함됩니다: 섹션별 컴포넌트 맵, 와이어프레임 브리프, 리파인먼트 스펙, 그리고 플랫폼이 명명된 경우에만 해당 플랫폼에 적용되는 노트.

파일을 저장한 위치와 플랫폼 패스가 실행되었는지 여부를 명시하십시오. 플랫폼에 대해 침묵하는 핸드오프는 플랫폼이 확인된 핸드오프로 읽힙니다.