Design Scout
기억에만 의존해 만든 웹사이트는 모든 웹사이트의 평균이 됩니다. 중앙 정렬 히어로, 그라데이션 블롭, 세 개의 기능 카드, 아무도 선택하지 않은 글꼴. 좋은 디자이너는 그림을 그리기 전에 실제 작업물을 먼저 살펴봄으로써 이런 함정을 피합니다. 이 스킬은 그것을 기본값으로 만듭니다: 먼저 살펴보고, 의도를 결정한 후, 빌드하세요.
프로세스는 다섯 단계입니다. 시간을 절약하려고 리서치 단계를 건너뛰지 마십시오. 리서치가 바로 시간을 절약해 주는 이유는 "이거 너무 평범해 보이는데, 다시 해봐"라는 반복을 없애주기 때문입니다.
- 인테이크: 비즈니스 파악
- 스카우트: 실제 레퍼런스 수집
- 브리프: 레퍼런스를 결정으로 전환
- 체크포인트: 사용자가 방향 승인
- 빌드 및 브리프 준수 여부 확인
1. 인테이크
리서치를 시작하기 전에 세 가지가 필요합니다. 누락된 것이 있다면 한 번의 메시지로 물어보세요:
- 니치: 웹사이트 종류 (치과诊所, B2B SaaS 인보이스, 스트리트웨어 스토어)
- 이름: 비즈니스 또는 제품명
- 소개: 무엇을 하거나 판매하는지, 대상, 차별점
사용자가 이미 이 정보를 제공했다면 다시 묻지 마세요.
같은 메시지에서 다음과 같은 선택적 질문을 제공하고 건너뛸 수 있음을 명확히 하세요. 각 질문은 리서치를 크게 개선하지만, 어느 것도 진행을 막아서는 안 됩니다:
- 대상 고객은 누구이며, 사이트가 그들에게 유도해야 할 단 하나의 행동은 무엇인가요?
- 사이트의 느낌을 설명하는 세 단어 (차분한, 시끄러운, 고급스러운, 장난기 있는, 기술적인...)
- (업종 상관없이) 좋아하거나 싫어하는 사이트가 있나요?
- 기존 브랜드 자산: 로고, 색상, 글꼴, 사진?
- 필요한 페이지나 섹션, 그리고 어떤 스택으로 빌드할 건가요?
건너뛰는 항목에 대해서는 합리적인 기본값을 선택하고 브리프에 가정으로 명시하여 사용자가 수정할 수 있게 하세요.
2. 스카우트
references/sources.md 파일을 지금 읽으세요. 이 파일은 각 출처, 무엇에 적합한지, 검색 방법, 그리고 단순 페칭을 차단하는 것들을 나열합니다.
먼저 검색어를 계획하세요. 아무것도 열기 전에 4~6개의 검색어를 작성하세요: 니치 자체("치과诊所 웹사이트"), 페이지 유형("예약 랜딩 페이지"), 분위기 단어("차분한 에디토리얼"), 그리고 이 니치보다 디자인 문화가 더 강한 인접 니치 (치과는 스킨케어 브랜드에서 배울 수 있고, 회계 도구는 Linear 스타일의 개발자 도구에서 배울 수 있습니다). 인접 검색어는 중요합니다: 니치 안에서만 찾으면 그 니치의 클리셰를 재생산하게 됩니다.
네 가지 렌즈를 다루세요. 열여덟 개의 사이트가 아닙니다. 출처 파일은 사이트를 렌즈별로 그룹화합니다. 각 렌즈에서 적어도 하나의 출처를 사용하고, 첫 번째 출처가 부족할 경우 더 사용하세요:
| 렌즈 | 질문 |
|---|---|
| 실제 웹사이트 | 이 분야의 실제 출시된 사이트들은 페이지를 어떻게 배치하나요? |
| UI 패턴 | 좋은 제품들은 이 특정 섹션(가격 책정, 내비게이션, 예약 양식)을 어떻게 해결하나요? |
| 비주얼 무드 | 어떤 느낌일 수 있을까요: 이미지, 텍스처, 색상, 아트 디렉션? |
| 타입과 색상 | 어떤 특정 글꼴과 팔레트인가요? |
또한 비즈니스의 직접 경쟁자 2~3곳을 보세요 (일반 웹 검색). 모방하려는 것이 아니라, 이 니치의 방문자가 무엇을 기대하는지, 모두가 무엇을 하는지 배우고, 디자인이 그와 차별화되도록 하기 위함입니다.
실제 사이트로 이동하세요. 갤러리 썸네일은 작고 종종 오래되었습니다. 갤러리 항목이 유망해 보이면, 그것이 가리키는 실제 라이브 웹사이트를 열고 확인하세요. 브라우저 도구가 있으면 스크린샷을 찍고, HTML만 읽으면 구조는 알 수 있지만 느낌은 알 수 없습니다.
각 유지할 항목을 기록하세요. 렌즈 전체에 걸쳐 6~10개를 목표로 하세요. 각 항목에 대해:
- 이름과 URL (실제로 열어본 실제 URL)
- 구체적으로 무엇이 효과적인지: 구체적으로 기술하세요 ("깔끔하고 현대적인"이 아닌 "좁은 제품 사진 옆에 왼쪽 정렬된 오버사이즈 세리프 헤드라인")
- 그 항목에서 차용할 한 가지
- 남겨둘 것
모호한 노트는 모호한 디자인을 만듭니다. 레퍼런스에 대해 구체적으로 좋은 점을 말할 수 없다면 버리세요.
정직 규칙. 이 세션에서 실제로 로드한 레퍼런스만 인용하세요. 본 적 없는 페이지의 사이트, URL 또는 설명을 절대 지어내지 마세요: 조작된 레퍼런스는 없는 것보다 나쁩니다. 사용자가 그것을 신뢰할 것이기 때문입니다. 출처가 차단되었거나, 로그인이 필요하거나, 비어 있다면 그렇게 말하고 다른 출처를 사용하세요. 웹 액세스가 전혀 없다면 리서치 단계를 실행할 수 없다고 사용자에게 분명히 말하고, 링크나 스크린샷을 붙여넣을지, 아니면 그 주의사항을 명시한 일반 지식으로 진행할지 물어보세요.
작업 규모에 맞게 조정하세요. 전체 사이트는 전체 패스를 받습니다. 단일 섹션이나 "빠른" 요청의 경우 짧은 패스를 수행하세요: 2개의 검색어, 3~4개의 레퍼런스, 몇 줄의 브리프입니다. 0으로 떨어지지 마세요.
3. 브리프
레퍼런스를 결정으로 전환하세요. references/brief-template.md의 템플릿을 사용하여 프로젝트에 design-brief.md로 저장하세요. 이렇게 하면 방향이 대화를 넘어 지속되고, 이후 작업을 이에 대해 확인할 수 있습니다.
브리프는 확정적이어야 합니다. 모든 항목은 레퍼런스 또는 비즈니스에 추적 가능한 이유가 있는 구체적인 선택입니다:
- 컨셉: 한 문장으로, 이 사이트를 이 비즈니스의 사이트로 만드는 아이디어
- 레이아웃: 섹션별로, 각 섹션의 구조적 아이디어
- 타입: 명명된 글꼴, 각각이 사용되는 위치, 그리고 구할 수 있는 곳 (라이선스 확인; 사용자가 라이선스를 가지고 있지 않은 경우 Google Fonts 또는 Fontshare와 같은 상업용 무료 글꼴 선호)
- 색상: 역할(배경, 텍스트, 강조 등)이 있는 16진수 값, 가독성 대비 확인됨
- 시그니처 요소: 방문자가 기억하고 다른 사람에게 설명할 한 가지
- 이미지 및 모션: 어떤 종류인지, 얼마나 절제되었는지
- 하지 않을 것: 이 디자인이 의도적으로 피하는 니치 클리셰와 일반 패턴
속성을 차용하지 말고 원칙을 차용하세요. 아이디어(비대칭 그리드, 글꼴 페어링, 섹션 페이싱 방식)를 가져오고, 레퍼런스의 로고, 이미지, 일러스트레이션, 카피 또는 레이아웃의 픽셀 수준 클론은 절대 가져오지 마세요. 여러 레퍼런스의 아이디어를 혼합하여 결과가 누군가의 복사본이 되지 않도록 하세요.
4. 체크포인트
빌드하기 전에 사용자에게 방향을 보여주세요: 컨셉 라인, 가장 강력한 3~4개의 레퍼런스와 링크, 팔레트, 글꼴, 섹션 개요, 시그니처 요소. 1분 안에 읽을 수 있을 정도로 짧게 유지하세요.
레퍼런스가 분명히 다른 두 방향을 제시하는 경우, 단순히 평균화하여 밋밋하게 만들기보다는 A와 B로 제시하고 추천을 제공하세요.
승인 또는 변경을 기다리세요. 승인되지 않은 방향으로 전체 사이트를 구축하는 것은 이 단계가 방지하려는 값비싼 실수입니다. 유일한 예외: 사용자가 미리 확인 없이 그냥 빌드하라고 말한 경우, 진행하고 브리프를 결과와 함께 표시하세요.
5. 빌드 및 확인
사용자의 스택으로 브리프에 따라 빌드하세요. 프론트엔드 또는 디자인 구현을 위한 다른 스킬을 사용할 수 있다면, 빌드에 사용하고 브리프를 입력으로 취급하세요.
빌드하는 동안:
- 이 비즈니스의 목소리로 실제 카피를 작성하세요. Lorem Ipsum 금지, "워크플로를 향상시키세요"와 같은 채우기 금지.
- 절대 사용자 후기, 고객 로고, 통계, 수상 또는 리뷰를 지어내지 마세요. 섹션에 필요하다면 명확하게 표시된 플레이스홀더를 넣고 사용자에게 무엇을 제공해야 하는지 알려주세요.
- 모바일을 의도적으로 디자인하세요. 데스크톱을 축소한 것이 아니라.
- 텍스트 대비를 읽기 쉽게 유지하고 대화형 요소를 키보드로 접근 가능하게 만드세요.
빌드가 완료되면 references/slop-check.md를 읽고 결과에 대해 실행하세요. 그런 다음 살펴보세요: 페이지를 열고, 가능하면 데스크톱과 휴대폰 너비로 스크린샷을 찍고, 브리프 및 레퍼런스와 비교하세요. 각 섹션에 대해 묻습니다: 방금 검색한 갤러리에서 통과할 수 있을까요? 부족한 부분을 수정하세요.
결과를 짧은 노트와 함께 제시하세요: 무엇이 빌드되었는지, 어떤 레퍼런스가 어떤 결정에 영향을 미쳤는지, 사용자가 채워야 할 플레이스홀더, 그리고 확인할 수 없었던 것.