실제로 효과적인 디자인용 Claude 프롬프트 19가지

디자인 작업이 막히는 원인은 기술보다 개념에 있는 경우가 훨씬 많습니다. 모호한 브리프, 말로 표현하기 어려운 아이디어, 판단의 근거를 자세히 설명해야 하는 클라이언트가 그 예입니다. 바로 이런 상황에서 디자인용 Claude 프롬프트가 빛을 발합니다. Claude는 시각물을 직접 만들지는 않지만, 시각물이 만들어지기 전과 그 주변에서 필요한 사고를 도와줍니다.

아래에는 브리핑, 타이포그래피·컬러 시스템, 인터페이스 문구, 디자인 피드백, 개발 인계까지 다루는 프롬프트 19개가 있습니다. 모두 바로 붙여 넣어 사용할 수 있습니다. Claude, GPT, Gemini를 한곳에서 제공하는 Chat Smith의 무료 AI 채팅에서 실행해 보고, 디자인 외 업무에 활용할 수 있는 더 다양한 Claude 프롬프트도 살펴보세요.

Claude는 사용자의 파일을 볼 수 없습니다. 디자인에 관해 아는 모든 것은 얼마나 정확히 설명하는지에 달려 있으므로, 결과물의 품질도 설명의 품질을 거의 그대로 따라갑니다. Claude Sonnet 5처럼 긴 컨텍스트를 처리하는 모델은 브리프, 브랜드 가이드, 세 차례의 피드백을 한 대화 안에 유지할 수 있습니다. 덕분에 일회성 답변이 아니라 반복적인 디자인 작업이 가능합니다. 유용한 프롬프트와 일반적인 프롬프트를 가르는 습관은 네 가지입니다.

의도한 바가 아니라 화면에 실제로 보이는 것을 설명하세요. 레이아웃, 위계, 간격, 색상 값, 글자 크기를 적으세요. 의도를 설명하면 의도에 대한 피드백만 받게 됩니다.

대상과 결정해야 할 행동을 명확히 하세요. ‘세 업체를 비교하는 B2B SaaS 구매자’는 ‘사용자’와 다른 조언을 이끌어 냅니다. 디자인이 유도해야 하는 결정은 미적 취향보다 중요합니다.

답만이 아니라 근거를 요청하세요. 설명할 수 없는 서체 조합은 클라이언트 회의에서도 방어할 수 없습니다. 모든 제안에는 근거가 함께 있어야 합니다.

확인 가능한 내용은 반드시 검증하세요. 폰트 제공 여부, 라이선스, 대비 비율은 모델이 자신 있게 말하면서도 틀릴 수 있는 정보입니다. 클라이언트에게 전달하기 전에 폰트 제작사와 대비 검사 도구에서 확인하세요.

무언가를 그리기 전 단계에 쓰는 프롬프트 네 가지입니다. 문제가 생긴 프로젝트 대부분은 이 단계에서부터 잘못되었습니다. 말로 만든 무드보드는 시각적 무드보드보다 훨씬 빠르게 수정할 수 있으며, 방향을 정한 뒤에는 텍스트 이미지 변환 도구가 유용합니다.

1. 크리에이티브 브리프 작성기

[프로젝트]를 위한 상세한 크리에이티브 브리프를 작성하세요. 클라이언트와 브랜드: [설명]. 대상 고객: [누구인지, 현재 무엇을 사용하는지, 무엇을 믿는지]. 브랜드는 [형용사 세 가지]라는 느낌을 주어야 합니다. 브랜드 개요, 대상 고객, 디자인 목표, 말투, 결과물, 제약 조건을 포함하세요. 마지막으로 내 입력 중 서로 모순되거나 디자인 근거로 삼기에는 지나치게 모호한 부분을 표시하세요.

2. 언어형 무드보드

[프로젝트]를 위해 실제로 서로 다른 시각적 방향 네 가지를 설명하세요. 각 방향마다 16진수 제안이 포함된 컬러 팔레트, 타이포그래피의 개성, 이미지 스타일, UI 컴포넌트의 느낌, 불러일으켜야 할 감정을 제시하세요. 정도가 아니라 종류가 달라야 하며, 같은 아이디어의 변형을 두 개 만들지 마세요. 마지막으로 가장 위험한 방향과 그 이유를 알려 주세요.

3. 카테고리 관행 점검

[카테고리]의 주요 업체들은 다음과 같이 시각적으로 자신을 표현합니다: [사이트, 색상, 서체, 이미지 설명]. 이 카테고리에서 모두가 따르는 관행을 찾아내세요. 그런 다음 실제 사용성 때문에 존재하는 관행과 단순한 모방인 관행을 구분하세요. 후자야말로 안전하게 차별화할 수 있는 영역입니다.

4. 대상 고객 요구 번역기

내 대상 고객은 [역할, 상황, 방문 시 하고 있는 일, 불안해하는 점을 설명]입니다. 이를 디자인 시사점으로 바꾸세요. 가장 먼저 봐야 할 것, 페이지를 불신하게 만드는 요소, 실제로 읽을 텍스트의 양, 사용할 가능성이 높은 기기와 환경을 알려 주세요. 각 항목을 바로 실행에 옮길 수 있을 만큼 구체적으로 작성하세요.

시스템 계층을 위한 프롬프트 네 가지입니다. 명명과 구조는 지금 바꾸면 비용이 적지만, 개발자가 이를 바탕으로 구현한 뒤에는 수정 비용이 커집니다.

5. 서체 조합

[브랜드와 업종 설명]에 어울리고 [형용사 세 가지]의 느낌을 주는 타이포그래피 조합 세 가지를 제안하세요. 각 조합마다 제목용 폰트, 본문용 폰트, 클라이언트 회의에서 설명할 수 있는 선정 근거를 알려 주세요. [Google Fonts / Adobe Fonts]에서 제공된다고 확신하는 폰트 패밀리만 사용하고, 라이선스를 직접 확인해야 할 곳도 알려 주세요.

6. 타입 스케일

[제품 유형]을 위한 [개수]단계의 타입 스케일을 기본 크기 [X]px로 만드세요. 각 단계의 크기, 줄 높이, 굵기, 용도와 모바일 값을 제시하세요. 그런 다음 서로 너무 가까워 디자이너가 혼용할 가능성이 있는 두 단계를 알려 주고, 둘 중 하나가 실제로 필요한지도 판단하세요.

7. 컬러 팔레트 이름 생성기

내 팔레트는 다음과 같습니다: [각 색상과 16진수 값 나열]. 브랜드는 [설명]입니다. 각 색상에 브랜드와 어울리는 인상적이고 기억하기 쉬운 이름을 붙이고, 시스템에서의 역할을 한 문장으로 설명하세요. 색상 자체를 묘사하는 이름은 피하세요. 그런 이름은 16진수 값 이상의 정보를 주지 못합니다.

8. 토큰 명명 규칙

[제품]을 위한 디자인 시스템을 만들고 있습니다. 브랜드 색상, 중성 색상 단계, 상태 색상, 배경/전경 쌍을 포괄하는 의미 기반 컬러 토큰 명명 규칙을 만드세요. 표로 정리하세요. 그리고 6개월 뒤 합류한 개발자가 내게 묻지 않고도 확장할 수 있도록 명명 원칙을 한 문단으로 설명하세요.

인터페이스 안의 문구를 위한 프롬프트 네 가지입니다. 이 문구는 대부분의 시각적 결정보다 경험에 더 큰 영향을 줍니다. 개발 인계 전 최종 문구를 AI 문법 검사기로 확인하고, 마케팅 사이트용 AI 광고 카피 생성기가 만드는 문구와도 톤을 일치시키세요.

9. 온보딩 마이크로카피

[제품]의 [개수]개 화면으로 이루어진 온보딩 흐름에 사용할 마이크로카피를 작성하세요. 각 화면마다 제목, 두 문장 이하의 본문, 버튼 라벨을 포함하세요. 톤: [설명]. 각 화면은 다음 화면으로 이어질 이유가 있어야 합니다. 기능을 설명하기 위해서만 존재하는 화면이라면 문구를 쓰는 대신 삭제하라고 알려 주세요.

10. 빈 상태와 오류 상태

[제품 영역 설명]의 빈 상태와 오류 메시지를 작성하세요. 각각 무엇이 일어났는지, 사용자가 무엇을 할 수 있는지, 버튼 라벨을 포함하세요. 사과하거나 사용자를 탓하지 말고 ‘이런’ 같은 표현도 쓰지 마세요. 오류가 우리 책임이면 솔직히 밝히고, 사용자가 해결할 수 없다면 우리가 대신 무엇을 하고 있는지 알려 주세요.

11. 폼 라벨과 도움말

내 폼의 필드는 다음과 같습니다: [목적과 함께 나열]. 각 필드의 라벨, 플레이스홀더, 도움말을 작성하세요. 라벨은 플레이스홀더 안에만 두지 말고 계속 보이게 하세요. 그런 다음 도움말이 라벨이 해야 할 일을 대신하는 필드와 완전히 없애도 되는 필드를 표시하세요.

12. 버튼과 작업 점검

[흐름 또는 화면 설명]의 모든 버튼 라벨은 다음과 같습니다: [나열]. 말투와 문법 형식의 일관성, 클릭 후 일어날 일의 모호함, 혼동하기 쉬운 두 라벨이 있는지 확인하세요. 문제가 있는 라벨을 다시 쓰고, 이 화면에서 시각적으로 가장 강조해야 할 단 하나의 작업을 알려 주세요.

검토 단계에서 사용할 프롬프트 네 가지입니다. 의도했던 모습이 아니라 현재 존재하는 그대로 디자인을 설명하세요. 이 섹션의 가치는 여기에 달려 있습니다. 미화한 설명은 미화한 피드백만 만들어 냅니다.

13. 레이아웃 피드백

내 디자인은 다음과 같습니다: [레이아웃, 위계, 색상, 서체, 간격, 첫 화면에 보이는 내용을 설명]. 대상 고객: [설명]. 유도하려는 행동: [명시]. 전환 중심 원칙에 따라 평가하고 예상 효과가 큰 순서대로 구체적인 개선안 다섯 가지를 제시하세요. 내가 가장 거부감을 느낄 만한 제안과, 그래도 그 제안이 옳은 이유도 알려 주세요.

14. 위계 점검

화면의 모든 요소를 나타나는 순서대로 적었습니다: [요소를 크기와 굵기와 함께 나열]. 사용자가 실제로 알아차릴 순서를 알려 주고, 내가 의도한 중요도 순서 [의도한 순서 명시]와 일치하는지 확인하세요. 다른 부분이 있다면 무엇을 바꿔야 하는지 알려 주세요.

15. 접근성 검토

내 디자인은 다음과 같습니다: [16진수 값을 포함한 색상, 글자 크기, 인터랙티브 요소, 상태 설명]. 색상 대비, 텍스트 크기, 터치 영역 크기, 의미 전달을 색상에만 의존하는지 여부, 포커스 상태, 움직임 측면에서 접근성을 검토하세요. 당신의 말만 믿지 않고 실제 대비 검사기와 스크린 리더로 확인해야 할 항목도 알려 주세요.

16. ‘무엇이 문제인지’ 진단

이 디자인에 문제가 있는데 정확히 표현할 수 없습니다: [가능한 한 자세히 설명]. 아직 해결책은 제안하지 마세요. 의도, 제약, 맥락에 관해 최대 여섯 가지 질문을 한 뒤 실제 문제가 무엇인지 가장 타당한 진단을 내려 주세요. 문제는 내가 계속 바라보는 바로 그 부분이 아닌 경우가 많습니다.

좋은 작업이 얼마나 잘 설명되느냐에 따라 승인되거나 거절되는 단계에 쓰는 프롬프트 세 가지입니다. 논리가 정리되면 문서 구조는 AI 제안서 생성기로 만들 수 있고, 한 화면이 아니라 흐름을 보여 줘야 할 때는 AI 스토리보드 생성기가 유용합니다.

17. 디자인 근거 설명

[만든 것과 색상, 서체, 구성, 이미지 등 구체적인 결정 설명]에 대한 디자인 근거를 세 문단으로 작성하세요. 대상은 비디자이너인 [창업자 / 클라이언트 / 이해관계자]입니다. 디자인 이론이 아니라 각 결정이 상대의 비즈니스에 주는 효과로 설명하세요. 추가 설명이 필요한 전문 용어는 쓰지 마세요.

18. 브랜드 보이스 가이드

[회사와 대상 고객 설명]을 위한 브랜드 보이스 및 개성 가이드를 만드세요. 원형, 설명이 포함된 네 가지 성격 특성, 톤 원칙, 사용하거나 피해야 할 단어, 전후 비교 카피 세 가지를 포함하세요. 그리고 오류 상태와 고객 지원에서 보이스가 어떻게 달라지는지에 관한 섹션도 추가하세요. 대부분의 보이스 가이드가 빠뜨리는 부분입니다.

19. 개발자 인계 메모

내 디자인은 다음과 같습니다: [컴포넌트, 상태, 동작 설명]. 개발자를 위한 인계 메모를 작성하세요. 고정 요소와 유동 요소, 각 중단점에서 컴포넌트가 작동하는 방식, 모든 인터랙션 상태, 긴 이름·누락된 이미지·빈 목록 같은 예상 밖 콘텐츠의 처리 방식을 포함하세요. 마지막으로 개발자가 물을 법하지만 내 설명에는 답이 없는 질문을 나열하세요.

디자인 작업에서는 프로젝트만 바뀔 뿐 같은 프롬프트를 반복해서 사용하므로 제대로 저장해 둘 가치가 있습니다. Chat Smith에서는 브리프 템플릿, 피드백 프롬프트, 인계 체크리스트를 원클릭 템플릿으로 보관하고, 클라이언트별로 묶고, 제품 팀 전체와 공유할 수 있습니다. 덕분에 브리프가 언제나 일관된 형태로 전달됩니다.

또한 여러 AI 모델인 Claude, GPT, Gemini, DeepSeek, Grok을 나란히 실행합니다. 디자인에서 실용적인 기능입니다. 모델마다 문체가 눈에 띄게 다르며, 개념적으로 풍부한 브리프를 잘 쓰는 모델이 가장 간결한 버튼 라벨을 만드는 경우는 드뭅니다. 같은 프롬프트를 두 모델에 보내는 데는 몇 초밖에 걸리지 않고, 어떤 결과를 사용할지도 대개 쉽게 결정할 수 있습니다.

먼저 파일에 미완성으로 남아 있는 디자인에 프롬프트 16번 ‘무엇이 문제인지 진단’을 사용해 보세요. 답하기 전에 질문을 던지는 유일한 프롬프트이며, 실제 문제를 찾아내는 경우가 가장 많습니다.