Back_to_Basics

{3줄 요약}

디자인 브리프는 무엇을 왜 만드는지 팀의 기준을 함께 먼저 맞추는 문서예요.
브리프가 분명해야 팀이 같은 문제를 보고 다른 방향으로 새지 않게 돼요.
핵심 질문에 답하는 브리프가 있으면 설계 판단과 협업이 실제로 훨씬 쉬워져요.

디자인 프로젝트를 시작할 때 가장 흔한 방식이 있어요.
"홈 화면을 개선해주세요"라는 요청을 받고 바로 스케치를 시작하는 거예요.

이렇게 하면 두 가지 문제가 생겨요.

첫째, 방향이 흔들려요.
개선의 기준이 없으니 팀마다 "더 예쁘게", "더 단순하게", "기능을 더 추가해서"라는 서로 다른 목표를 향해 달려요.

둘째, 진짜 문제를 안 풀 수 있어요.
"홈 화면을 개선하자"가 아니라 "사용자가 원하는 상품을 못 찾는 게 진짜 문제"일 수 있어요.
홈 화면이 아니라 검색이나 카테고리 구조를 고쳐야 했던 거예요.

디자인 브리프는 이 상황을 막아줘요.

좋은 브리프는 길지 않아도 돼요.
아래 다섯 가지 질문에 답할 수 있으면 충분해요.

1. 우리가 해결하려는 문제는 무엇인가요? "홈 화면이 복잡하다"는 문제가 아니에요.
"사용자가 처음 방문했을 때 무엇을 해야 할지 모른다"가 더 구체적인 문제예요.

2. 누구를 위한 건가요? 모든 사람이 아니에요.
디자인 결정을 내릴 때 "이 사람은 어떻게 쓸까"라는 기준이 될 구체적인 사용자를 정해야 해요.

3. 어떻게 하면 성공인가요? "사용자 경험이 좋아지면"은 측정할 수 없어요.
"첫 방문 후 회원가입 전환율이 5% 이상 올라가면"은 측정할 수 있어요.

4. 어떤 제약이 있나요? 기술 제약, 일정, 기존 디자인 시스템 규칙, 법적 요건 - 이걸 모르면 나중에 다시 뒤집어야 할 설계가 나와요.

5. 우리가 모르는 것은 무엇인가요? 이 질문이 있어야 리서치가 시작돼요.
"사용자가 왜 중간에 나가는지 모른다" - 이게 리서치 과제가 되고, 답이 나오면 브리프가 업데이트돼요.

Dan Olsen은 《The Lean Product Playbook》에서 제품 정의의 핵심은
"누구를 위해, 어떤 문제를, 어떻게 해결하는가"라고 말해요.

브리프를 한 단락으로 써야 한다면 이 형식을 써보세요.

"[이런 사용자]는 [이런 상황에서] [이런 어려움]을 겪어요.
우리는 [이런 방식으로] 이 문제를 해결하려고 해요.
성공하면 [이런 변화]가 일어날 거예요."

예시:

"처음 방문한 20~30대 사용자는 우리 앱에서 원하는 상품을 찾는 데 평균 3분 이상 걸려요.
우리는 카테고리 구조를 행동 기반으로 재정의해서 탐색 시간을 줄이려고 해요.
성공하면 첫 방문 후 15분 안에 구매 완료율이 20% 올라갈 거예요."

처음에 쓴 브리프가 완벽할 필요 없어요.
리서치를 하면 문제 정의가 바뀔 수 있어요.
가설을 실험하면 성공 기준이 조정될 수 있어요.

브리프는 팀의 현재 이해를 담은 문서예요.
계속 업데이트하면서 방향을 정렬하는 도구예요.

문제 정의에서 시작하는 방법은 문제 정의가 디자인의 80%에서 더 깊이 다뤄요. 브리프 작성 전에 해야 할 리서치는 디자인 리서치 기본을 먼저 보세요.