브랜드 아이덴티티 빌더

브랜드 아이덴티티 빌더은(는) 무엇을 하나요?

Lovable은 여러분이 설명하는 대로 제품을 만들지만, 대부분의 사람들은 자신의 제품이 어떻게 보이고, 어떻게 들리며, 무엇을 대표할지 미리 정해두지 않습니다. 그래서 모두가 똑같은 평범한 그라데이션 디자인을 얻게 됩니다. 이 스킬은 v1 제품에 실제로 필요한 브랜드 결정을 내리고, 빌더가 따라할 수 있는 형태로 기록합니다.

사용 시기

• 빌드를 시작하려고 하는데 아직 색상, 폰트, 보이스를 정하지 못한 경우
• Lovable 빌드 결과물이 계속 평범하게 나오는 경우
• 제품 이름은 있지만 그 이유가 없거나, 아예 이름이 없는 경우
• 툴, 팀원, 또는 외부 계약자가 여러분 없이도 따라할 수 있는 브랜드 문서가 필요한 경우

입력

짧은 브리프면 충분합니다: 제품이 무엇을 하는지, 누구를 위한 것인지, 그리고 이미 결정된 사항(이름, 마음에 드는 색상, 닮고 싶지 않은 경쟁사 등). 사용자가 이미 이름을 가지고 있다면 그 이름을 유지하고 그 이유를 설명하세요. 아무도 요청하지 않은 제품 이름을 바꾸지 마세요.

프로세스

사용자에게 한 번에 하나의 질문만 하고, 브리프가 이미 답하지 않은 부분에 대해서만 질문하세요.

1. 상황 파악. 선택을 시작하기 전에 브리프를 바탕으로 다음 네 가지 질문에 스스로 답하세요. 브리프가 명확히 하지 않은 부분만 사용자에게 물어보세요.

   • 실제로 무엇을 하는가? ("펫 케어의 권한 부여"가 아니라, "혼자 일하는 모바일 애견 미용사를 위한 약속 예약 및 경로 배정")
   • 누가 이 제품을 신뢰해야 하는가? 주요 신뢰 관계와 하나의 보조 관계를 지정하세요.
   • 작업의 긴장감은 무엇인가? 강력한 브랜드는 함께 어울리지 않을 것 같은 두 요소(물류와 평온함, 데이터와 따뜻함)가 만나는 지점에 위치합니다. 이름과 태그라인은 그 긴장감 속에서 살아갑니다.
   • 제품이 작동해야 하는 가장 작은 공간은 무엇인가? 파비콘, 앱 아이콘, 문자 메시지 헤더입니다. 그 크기에 맞춰 디자인하세요.

2. 이름(필요한 경우만). 운영 측면을 나타내는 단어 10개와 관계 측면을 나타내는 단어 10개를 나열한 후, 각각에서 하나씩 짝지으세요. 각각 한 줄짜리 근거와 함께 두세 가지 옵션을 제시하세요. 각 이름을 테스트하세요: 한 번에 말할 수 있는가, URL로 사용 가능한가, 낯선 사람이 최소 절반은 이해할 수 있는가?

3. 색상: 각각 역할이 있는 다섯 가지 색상.

   • 기본: CTA 및 주요 브랜드 순간에 사용, 높은 에너지
   • 어두운: 깊이와 대비를 위해 사용. 순수한 검정보다 따뜻함.
   • 밝은: 표면 및 어두운 배경 위의 텍스트용
   • 보조: 기본 색상을 덜 강렬하게 만드는 균형추
   • 강조: 숫자, 하이라이트, 강조용

   각 색상을 색상명이 아닌 브랜드 의미로 명명하세요("다크 네이비"가 아니라 "나이트 루트"). 대비를 확인하세요: 본문 텍스트는 할당된 모든 배경에서 WCAG AA(4.5:1)를 통과해야 합니다.

4. 타이포그래피: 두 가지 폰트. 헤드라인이나 숫자를 충분히 강조할 수 있는 디스플레이 폰트 하나. 작은 크기에서도 잘 읽히는 본문 폰트 하나. 모든 빌더가 로드할 수 있도록 Google Fonts에서 선택하세요. 두 폰트는 무게에서 대비되어야 하지만 스타일에서 싸우지 않아야 합니다: 무겁고 개성 있는 디스플레이 폰트와 조용하고 읽기 쉬운 본문 폰트.

5. 태그라인: 두 개의 짧은 문장. 첫 번째는 운영적 행동, 두 번째는 관계적 약속입니다. 접속사는 사용하지 마세요. 병치 자체가 의미이기 때문입니다. 총 4~8단어. ("밴을 예약하세요. 평온을 유지하세요.")

6. 보이스: 정확히 네 가지 원칙. 각각은 대비 쌍, 즉 "X, 하지만 Y는 아님"이며, 하나의 예문과 그것이 대체하는 일반적인 버전을 포함합니다. 예문은 v1에서 제품이 실제로 하는 일만 설명해야 합니다. 빌더와 이후 스킬이 이를 카피로 재사용하기 때문입니다. 성격 형용사("친근한, 전문적인")는 모든 브랜드가 주장하므로 원칙이 될 수 없습니다.

7. 빌드 규칙 작성. 결정 사항을 빌더가 따르는 지침으로 변환하세요: 어떤 색상이 어떤 테마 토큰에 들어가는지, 폰트 로딩, 버튼 및 제목 규칙, 그리고 간단한 금지 목록. 이 섹션이 문서를 단순히 예쁘게 만드는 것이 아니라 Lovable에 유용하게 만듭니다.

8. 저장. [references/brand-system-template.md](references/brand-system-template.md)를 사용하여 brand-system.md를 작성하세요. 한 페이지로 유지하세요.

출력

• brand-system.md: 제품 문장, 대상 고객, 이름 근거, 태그라인, 사용 규칙이 포함된 팔레트 표, 폰트 쌍, 네 가지 보이스 원칙, Lovable용 빌드 규칙을 포함한 한 페이지.
• 사용 방법에 대한 짧은 메모: 전체 파일을 Lovable 프로젝트 지식(프로젝트 설정)에 붙여넣은 후, 첫 번째 빌드 프롬프트를 "프로젝트 지식의 브랜드 시스템을 따르세요."로 시작하세요.
• 선택 사항: 사용자가 요청하는 경우, 색상 견본과 폰트 샘플이 포함된 단일 페이지 HTML 미리보기.

가드레일

• 결정하되, 설문 조사하지 마세요. 하나의 팔레트와 하나의 폰트 쌍을 추천하고 그 이유를 설명하세요. 이름에 대해서만 대안을 제시하세요.
• AI 색상 이름 없음. "세이지", "슬레이트", "웜 토프"는 색상이 어떻게 보이는지는 말하지만 무엇을 의미하는지는 말하지 않습니다.
• 태그라인으로 위장한 미션 스테이트먼트 없음. "함께 더 나은 커뮤니티 구축"은 포기한 미션입니다.
• v1만. 로고 디자인, 일러스트레이션 스타일, 사진 방향은 나중으로 미룰 수 있습니다. 사용자가 그쪽으로 흘러가면 그렇게 말하고 문서의 "나중에" 항목에 기록하세요.
• 대비는 선택 사항이 아닙니다. 어떤 쌍이 AA를 실패하면 저장하기 전에 변경하세요.

관련 스킬

다음 스킬은 brand-system.md를 읽습니다: pitch-narrative-architect는 보이스 원칙을 사용하고, founder-site-copywriter는 전체 문서를 사용합니다.