문제 정의를 명확하게 하는 방법

– 주니어 기획자를 위한 실전 사고 구조 가이드

기획을 하다 보면 이런 피드백을 많이 듣습니다.

▪ “문제가 좀 모호한 것 같아요.”

▪ “이게 문제인가요, 현상 아닌가요?”

▪ “그래서 이게 매출에 어떤 영향을 주죠?”

▪ “리서치는 했는데… 보고서로 정리가 안 돼요.”

▪ “팀원마다 말하는 문제가 다 달라요.”

기획자라면 이와 같은 고민을 많이 해보셨을 것 같아요.

하지만

문제 정의가 어려운 게 아니라,

문제를 ‘구조적으로’ 정의하는 훈련을 받아본 적이 없었던 것입니다.

이 글에서는 문제 정의를 위한 사고 프레임을 정리해보려고 합니다.

우리가 훈련해야 할 사고 구조

현업 개발자의 머리 속에서 문제 정의는 이렇게 흘러갑니다.

"관찰 기반 주장 → 증거 기반 문제 정의 → 사용자 행동 변화 → KPI 영향 → 해결 전략 도출

그리고 이 사고 흐름을 훈련하기 위해서 참고 자료를 활용해보자면,

아래와 같이 NN/g(Nielsen Norman Group)의 프레임을 활용합니다.

▪ Evidence-Based UX

▪ Problem Statements

▪ Task Analysis

▪ Measuring UX

▪ Search & IA 원칙

핵심은 단 하나입니다.

"“감”이 아니라, 검증된 UX 원칙과 근거 기반 사고로 문제를 정의하는 것.

왜 우리는 문제 정의에서 계속 막힐까?

1. 불편함 = 문제라고 생각한다

“리뷰가 부족하다.”

“검색이 불편하다.”

이와 같은 불편함은 문제 정의가 아니라, 현상이거나 느낌입니다.

2. 해결책을 문제처럼 쓴다

“자연어 검색이 필요하다.”

"AI 추천 기능을 만든다."

기획자에게 필요한 것은 해결책을 먼저 설명하는 것이 아니라,

그 앞에서 설득해야하는 이유가 있어야 합니다.

이미 답을 정해두고 시작하면 문제를 제대로 보지 못합니다.

3. 관찰과 해석이 섞여 있다

“사용자는 프로모션을 신뢰하지 않는다.”

"사용자들이 검색이 불편해서 구매하다가 이탈하기도 한다."

내가 작성한 기획서의 문장을 잘 살펴보세요.

현상에 대한 관찰인지, 해석인지 구분해보고,

그 과정에서 주관적인 해석은 덜어냅니다.

여기서는 필요하다면 통계, 자료, 사용자 조사가 추가됩니다.

4. 문제를 구분하지 않는다

고객이 사용자 입장에서 느낄 수 있는 불편한 지점은 다양하게 있을 수 있습니다.

그렇지만, 비즈니스적으로 가치가 있는 문제는

사용자의 희망사항이나 있으면 좋을 것 같은 기능이 아니라

사용자의 불편함과 고통에 직결된 문제일수록 우선순위가 높아야 합니다.

가장 많은 기획서에서 보이는 주제들이 '있으면 좋을 것 같은 AI 기능'이 많습니다.

기획서의 문제 정의 앞에는

'왜 그 문제를 우리가 선정했는지'에 대한 구체적인 기준과 근거가 있어야 합니다.

5. 비즈니스 연결이 빠져 있다

그래서 문제를 채택 했다고 가정합니다.

그런데 그 문제가 왜 우리 회사에 필요가 있을까요?

그 문제를 해결해주지 않는다면?

▪ 우리 매출에?

▪ 우리 전환율에?

▪ 우리 재방문율에?

어떤 영향을 미치나요?

많은 기획서들이 단순 개인 프로젝트와 사이드 프로젝트에 머무는 큰 이유입니다.

우리는 특정 회사나 기업에 소속되어 있다고 가정하고

철저하게 상상하고 근거를 찾아야 합니다.

위의 질문에 답하지 못하면 기업이 투자할 의미가 있을까요? 설득이 되지 않습니다.

문제 정의는 반드시 비즈니스 지표와 연결 가능한 수준까지 구체화되어야 합니다.

NN/g 관점에서 보는 문제 정의의 4가지 축

1. Problems Are About Users, Not Solutions

문제는 기능의 부재가 아닙니다.

문제는 사용자의 목표 달성 실패 지점입니다.

▪ 기능 중심 사고: “검색 기능이 부족하다.”

▪ 사용자 중심 사고: “사용자가 원하는 상품을 찾지 못한다.”

핵심 전환은 이것입니다.

서비스 중심 → 사용자 목표 중심

가장 먼저 시작해야하는 부분입니다.

2. Write Problem Statements, Not Feature Requests

좋은 문제 정의는 다음을 포함합니다.

▪ 누가 (고객이)

▪ 어떤 맥락에서 무엇을 하려고 했는데 (목표와 상황)

▪ 어떤 장애를 겪고 (페인포인트)

▪ 그 결과 어떤 영향이 발생하는가 (고객의 문제)

처음부터 문제 정의를 기능서처럼 쓰지 않습니다.

▪ 자연어 검색이 필요하다

▪ 추천 기능을 강화해야 한다

구체적인 문제 정의

사용자는 원하는 상품을 빠르게 찾고 싶지만,

검색어 입력 방식이 제한적이어서 탐색에 실패하고, 검색을 포기하거나 이탈한다.

해결책은 문제 정의 이후에 나옵니다.

참고 : 기획자들이 문제정의와 현상을 혼동하는 실수는 자주 일어납니다.

기존 문장:

"필요한 정보를 얻기 위해 외부 커뮤니티로 이탈한다."

→ 이건 관찰입니다.

문제 정의로 확장해보면:

구매를 고려하는 사용자는 상품의 실제 착용감과 품질에 대한 신뢰 가능한 정보를 얻고자 하지만,

플랫폼 내 리뷰 정보가 충분히 구조화되어 있지 않다고 인식하여 외부 채널로 이동한다.

그 결과 구매 여정이 중단되거나 경쟁 플랫폼으로 전환될 가능성이 증가한다.

→ 길어 보이나요? 하지만, 이 정도 구체성이 드러나야 합니다.

→ 말로 설명해 보세요. 누군가 앞에 있다고 가정하고 읽어보면 그 이유가 나옵니다.

3. Evidence-Based UX

단순한 아이디어나 의견은 문제 정의가 아닙니다.

UX 의사결정에는 반드시:

▪ 관찰

▪ 데이터

▪ 행동 근거

가 있어야 우리가 말하는 근거 있는 기획이 될 수 있습니다.

조금 더 들여다 보기 위한 지표를 사용해 보세요.

예:

▪ 세션 이탈률은?

▪ 상품 상세 → 외부 이동 행동은?

▪ 리뷰 스크롤 깊이는?

▪ 인터뷰 인용은?

설득력을 높이려면, 숫자와 관찰을 근거로 말해야 합니다.

숫자로 설명할 수 없다면, 아직 문제 정의가 충분히 구체화되지 않은 것입니다.

4. Measuring UX

UX는 측정 가능해야 합니다.

문제 정의는 반드시 다음 중 하나와 연결됩니다:

▪ 전환율

▪ 이탈률

▪ 재방문율

▪ 세션 대비 구매율

▪ 검색 이탈률

많은 기획서에서 측정 가능한 지표 또는 비즈니스 가치 판단 부분이 빠져있습니다.

사용자의 문제와 해결책만으로 기획서를 끝내버리지 않는 것이 좋습니다.

그 외의 첫 기획서 작성해서 참고할만한 팁을 정리합니다.

문제를 숫자로 질문하자

문제를 선정할 때 이렇게 질문해보세요.

▪ 평균 클릭 수는?

▪ 필터 사용률은?

▪ 필터 후 구매 전환율은?

▪ 첫 화면 상품 개수는?

▪ 탐색 전략 변경이 발생하는가?

추상적 문제를 수치로 바꾸는 순간 설득력이 생깁니다.

JTBD 관점 적용

기획 공부를 하다보면 자주 나오는 JTBD 방법론을 사용해 보세요.

JTBD(Jobs To Be Done)는 말합니다.

: 사용자는 제품을 사는 것이 아니라, 어떤 일을 해결하기 위해 고용한다는 점

사용자의 목적은 단순히 '무신사를 쓰고 싶어!' 가 아닙니다.

사용자가 무신사를 고용/이용하는 이유는

“스타일에 맞는 옷을 빠르고 확신 있게 사고 싶다.” 라는 구체적인 목표가 있기 때문입니다.

이 관점으로 문제를 다시 쓰면

기능 중심 사고에서 벗어날 수 있습니다.

UX 문제는 반드시 행동 변화로 나타난다

문제 정의 파트에서 눈에 보이는 현상과 관찰을 추상적으로만 쓰지 않습니다.

자주 나오는 예:

▪ 탐색 실패 → 검색 이탈 증가로 명시

▪ 신뢰 부족 → 구매 전환율 감소로 명시

▪ 선택 과다 → 세션 대비 구매율 저하로 명시

비즈니스 효과와 연결하는 법

문제 정의는 반드시 이 질문으로 끝나야 합니다.

“그래서?"

"그래서 매출, 전환율, 재방문율, 브랜드 신뢰도 중 무엇에 영향을 미치는가?”

이 질문에 답하지 못하면

문제 정의는 끝나지 않았습니다.

근거는 리서치 결과에서부터

열심히 리서치를 했다면, 리서치 결과가 정리되어 있어야 합니다.

대부분의 리서치 보고서는 4단계의 표준 보고서 구조에 따라 정리합니다.

1.관찰 (Fact)

2.패턴 (Pattern)

3.문제 정의 (Problem Statement)

4.비즈니스 영향 (Impact)

기획자 설득을 위한 3가지 프레임

1.의견과 증거를 구분

▪ 이 아이디어/페인포인트는 단순히 현상이나 관찰인가?

▪ 이건 나만의 해석인가?

▪ 객관적으로 뒷받침할 증거는 무엇인가?

2.JTBD 관점 적용

▪ 사용자의 진짜 목적은 무엇인가?

▪ 우리는 기능을 만드는가, 사용자의 목표 달성을 돕는가?

3.“측정 가능하게 다시 써라”

▪ 정성 근거 n개

▪ 정량 가설 n개

▪ KPI나 OKR 목표를 작성

최종 결론

문제정의를 작성하는 과정에서

문제는 불편함만 정의하는 것이 아닙니다.

문제는 사용자의 목표 달성을 방해하는 것이며,

문제는 사용자가 목표를 달성하거나 실패할 수 있는 특정 지점입니다.

그리고 그 행동 변화는 반드시 비즈니스 지표로 연결됩니다.

이 글이 문제를 더 명확하게 정의하고 싶은 주니어 기획자분들께 도움이 되었으면 합니다. :)