기획·디자인 개요와 문제 정의

기획·디자인이 답하는 질문

• 문제와 해결책을 구분한다
• 가정과 근거를 연결해 검증 가능한 가설을 만든다
• 첫 버전의 포함·제외 범위와 성공 지표를 정한다

문제에서 가설까지

기획·디자인은 무엇을 하는가

기획·디자인은 정해진 기능을 보기 좋게 꾸미는 단계가 아닙니다. 어떤 문제를 해결할 가치가 있는지 확인하고 사용자가 이해할 수 있는 흐름을 만듭니다. 구현 전에는 가장 위험한 가정을 검증합니다.

1문제 발견 → 사용자 근거 → 정보와 행동 흐름 → 프로토타입 검증 → 반복 패턴 정리

기획자와 디자이너는 개발자와 함께 제약을 확인하고 사용자에게 가정을 검증하며 답을 정합니다.

시작하기 전에

좋은 제품 기획은 누구의 어떤 문제를 왜 지금 해결하는지 합의하는 문서입니다. 기능 목록만으로는 부족합니다. 해결책을 정하기 전에 관찰한 문제와 추측을 분리하세요.

문제 정의

문제 문장은 사용자, 상황, 어려움, 영향의 네 요소로 씁니다.

신입 부원은 첫 세션 전에 준비할 도구가 흩어져 있어 설치 누락으로 실습 시작이 늦어진다.

“앱이 필요하다”는 해결책이고 문제가 아닙니다. 인터뷰, 문의 기록, 행동 데이터처럼 문제를 뒷받침하는 근거를 함께 적습니다.

사용자와 핵심 상황

• 주 사용자는 누구인가?
• 문제는 언제, 얼마나 자주 발생하는가?
• 현재 어떤 방식으로 해결하고 있는가?
• 해결하지 않으면 어떤 비용이나 불편이 생기는가?

사용자를 너무 넓게 잡으면 우선순위를 정할 수 없습니다. 첫 버전은 가장 자주, 가장 크게 불편을 겪는 한 집단에 집중합니다.

가설 세우기

가설은 “만약 우리가 A를 제공하면, B 사용자는 C 행동을 더 많이 할 것이다. D 지표로 확인한다” 형식으로 작성합니다.

1가설: 세션별 준비 체크리스트를 제공하면2신입 부원의 실습 시작 지연이 줄어든다.3지표: 시작 10분 안에 환경 확인을 마친 인원 비율

범위 정하기

필수 흐름 하나를 먼저 고릅니다. 첫 버전에서 제외할 기능도 명시해야 일정과 품질을 지킬 수 있습니다.

1. 사용자가 달성해야 하는 결과를 적습니다.
2. 그 결과에 반드시 필요한 행동만 남깁니다.
3. 있으면 좋지만 검증과 무관한 기능은 제외 목록으로 보냅니다.
4. 실패했을 때 복구할 경로를 확인합니다.

성공 기준

페이지 조회수처럼 결과와 약하게 연결된 수치만 보지 않습니다. 과업 완료율, 소요 시간, 재방문, 오류율처럼 사용자 행동과 가까운 지표를 선택합니다. 측정 기간과 기준값도 함께 적습니다.

기획 산출물

• 한 문장 문제 정의
• 핵심 사용자와 사용 상황
• 검증할 가설과 지표
• 첫 버전 범위와 제외 범위
• 사용자 흐름 초안

기획 의사결정 도구

문제, 가설, 기능, 지표를 한 문장에 섞으면 무엇을 검증하는지 흐려집니다. 각 항목을 별도 열로 두고 연결 관계를 확인하세요.

우선순위는 점수가 아니라 대화 도구

RICE나 Impact/Effort 표는 결정을 대신하지 않습니다. 근거가 약한 숫자는 범위만 정밀해 보이게 만듭니다.

참고: “제외”는 영구 폐기가 아니라 현재 가설을 검증하는 데 필요하지 않다는 뜻입니다. 결정 날짜와 다시 검토할 조건을 남기세요.

의사결정 기록

1### 결정: 첫 버전은 세션 준비 체크에 집중한다2- 날짜: 2026-03-103- 근거: 설치 문의와 지연 관찰4- 선택: 세션별 준비물 + 완료 상태5- 제외: 채팅, 알림 자동화6- 재검토: 준비 완료율이 80%를 넘은 뒤

기획 리뷰 확인 항목

• 문제 문장에 특정 사용자와 상황이 있습니다.
• 사실과 가정을 구분했습니다.
• 첫 버전에서 제외할 범위가 명시되어 있습니다.
• 지표에 기준값과 측정 기간이 있습니다.

제품 브리프 예제

이 문서의 인용·숫자·날짜·결정 기록은 설명을 위한 가상 사례입니다. 실제 운영 데이터나 조사 결과로 인용하지 않습니다. 목표 80%도 권장 정답이 아니라 기준선과 운영 여건에 따라 합의할 예시입니다.

예제: 세션 신청 경험 브리프

다음 틀을 한 페이지로 작성합니다.

1## 문제2[사용자]는 [상황]에서 [어려움]을 겪어 [영향]이 생긴다.3
4## 근거5- 관찰 또는 문의:6- 아직 확인하지 못한 가정:7
8## 가설9만약 [해결책]을 제공하면 [행동 변화]가 일어날 것이다.10
11## 첫 버전12- 포함:13- 제외:14
15## 성공 기준16- 지표:17- 기준값:18- 측정 기간:

범위 리뷰

기획자·디자이너·개발자가 함께 읽고 각자 다르게 이해한 단어를 표시합니다. “빠르게”, “편리하게”, “실시간”처럼 측정되지 않는 표현은 관찰 가능한 행동으로 바꿉니다.

결정 기록

첫 버전에 제외한 항목마다 다시 검토할 조건을 한 줄로 남깁니다. 우선순위 점수보다 결정 근거와 불확실성을 기록하는 것이 중요합니다.

1주 세션: 문제를 기능 목록과 분리하기

권장 100분: 사례 분류 20분, 문제 브리프 30분, 팀 범위 합의 25분, 상호 리뷰 25분입니다. 개발자·디자이너가 같은 문제를 다르게 이해하는 단어부터 표시합니다.

먼저 ‘세션 신청 앱 만들기’를 사용자·상황·어려움·영향이 있는 문제 문장으로 바꿉니다. 실제 근거가 없다면 ‘현재 가설’이라고 적고 2주 인터뷰에서 확인합니다. 가상의 숫자로 빈칸을 채워 근거가 있는 것처럼 만들지 않습니다.

다음으로 준비물 목록·신청 상태 확인·채팅·추천 중 이번 가설을 확인하는 최소 흐름을 선택합니다. 기능마다 포함 이유 또는 제외 이유와 재검토 조건을 한 줄씩 씁니다. 구현 비용은 개발자에게 확인한 추정과 미확인 추정을 구별합니다.

지표는 분자·분모·측정 시점을 명시합니다. 예를 들어 준비 완료율은 ‘세션 시작 전 환경 확인을 마친 참여자 / 확인 대상 참여자’처럼 정의하고 실제 수집 가능성과 동의 범위를 검토합니다. 표본이 적으면 비율뿐 아니라 실제 인원과 실패 원인을 함께 기록합니다.

제출물은 한 페이지 브리프, 포함·제외 범위, 확인할 가정 두 개, 담당자와 다음 행동입니다. 완료 기준은 팀원이 기능 이름 없이도 문제와 성공 상태를 설명하고 사실·가정·목표가 구별되는 것입니다.

더 읽어보기

• GOV.UK Discovery phase
• GOV.UK Measuring success
• Atlassian Product requirements

다음 단계

사용자 리서치에서 제품 브리프의 가정을 실제 행동과 관찰로 확인합니다.

연결된 PBL 미션과 VOD

PM은 ‘PM업무, 강의 하나로 정리하기’, Figma는 ‘Figma로 앱 디자인부터 포트폴리오까지’를 뜻합니다.

강좌 안내: 참고 강좌 1 · 참고 강좌 2. 이 문서는 영상 전체를 옮긴 전사 자료가 아닙니다. 세부 내용은 위 공식 문서에서 확인합니다.