Back_to_Basics

{3줄 요약}

문제 정의는 무엇을 만들지보다 무엇을 풀지 먼저 정하는 설계의 출발점이에요.
문제를 잘못 잡으면 정교한 해결책도 실제 효과를 끝내 만들지 못하게 돼요.
문제를 다시 정의할 수 있으면 프로젝트의 방향과 우선순위가 함께 바뀌어요.

잘 만들었는데 아무도 안 써요

디자인을 오래 하다 보면 이런 상황을 만나요.
팀 전체가 몇 달을 공들여 만들었어요.
완성도도 높아요.
그런데 출시하고 나서 아무도 안 써요.
지표가 움직이지 않아요.

이런 경우의 상당수는 기능 문제가 아니에요.
잘못된 문제를 풀었기 때문이에요.

"무엇을 만들까"보다 "무엇이 문제인가"를 먼저 충분히 다루지 않은 결과예요.

문제 정의가 바뀌면 해결책이 바뀌어요

Jake Knapp은 《Sprint》에서 이렇게 말해요.
"문제를 제대로 이해하지 않은 채 해결책으로 뛰어드는 것이 가장 흔한 실수다. "

같은 상황도 문제를 어떻게 정의하느냐에 따라 완전히 다른 방향으로 가요.

예를 들어볼게요.
어떤 커머스 앱에서 '장바구니 이탈률'이 높아요.

정의 A: "결제 화면이 복잡해서 이탈해요" → 해결책: 결제 화면 UI 개선

정의 B: "배송비가 예상보다 높게 나와서 이탈해요" → 해결책: 배송비 예측 정보를 더 빨리 보여주기

정의 C: "사용자가 상품을 '나중에 사기 위해' 장바구니에 담아요" → 해결책: 위시리스트 기능 강화, 장바구니와 분리

같은 지표 문제를 세 가지 다른 방식으로 정의했더니 해결책이 완전히 달라졌어요.
어떤 정의가 맞는지는 데이터와 사용자 조사가 알려줘요.

Slack의 시작은 게임이었어요

Slack의 탄생 이야기는 문제 재정의의 좋은 사례예요.

Slack을 만든 Stewart Butterfield의 팀은 원래 글리치(Glitch)라는 온라인 게임을 개발하고 있었어요.
게임은 실패했어요.
하지만 그 과정에서 팀 내부 커뮤니케이션을 위해 만든 도구가 있었어요.

그 도구가 정말 잘 작동했어요.

팀은 문제를 재정의했어요.
"우리가 진짜 풀고 있는 문제는 게임이 아니라 팀 커뮤니케이션이다. "

그 재정의에서 Slack이 나왔어요.
지금 세계에서 가장 많이 쓰는 업무 메신저 중 하나예요.

문제를 제대로 정의하는 방법

"왜"를 다섯 번 물어요 (5 Whys) 도요타가 만든 방법이에요.
문제가 발생했을 때 "왜?"를 다섯 번 반복하면 표면 원인이 아니라 근본 원인에 도달해요.

예시: 1. 왜 사용자가 이탈해요?
→ 결제를 완료하지 않아서 2. 왜 결제를 완료하지 않아요?
→ 중간에 오류가 생겨서 3. 왜 오류가 생겨요?
→ 카드 정보 입력 화면에서 4. 왜 그 화면에서 오류가 생겨요?
→ 입력 형식 안내가 없어서 5. 왜 안내가 없어요?
→ 디자인 단계에서 고려하지 않았어서

근본 원인: 설계 단계에서 오류 케이스를 고려하지 않은 것.

HMW 질문으로 바꿔요 (How Might We) 문제를 발견하면 "어떻게 하면 ~할 수 있을까?" 형식으로 바꿔요.
이렇게 하면 문제가 해결 가능한 기회로 보이기 시작해요.

예: "사용자가 설정 화면을 찾지 못한다" → "어떻게 하면 사용자가 설정을 더 쉽게 찾을 수 있을까?"

이 원칙을 실무에서 적용하는 첫 질문:

지금 해결하려는 것이 진짜 문제인가요, 아니면 증상인가요?
이 정의가 맞다는 증거가 있나요?
다른 방식으로 정의한다면 어떻게 될까요?

문제를 발견하는 구체적인 실행 방법은 디자인은 문제 해결이다를 참고하세요. 디자인씽킹에서 Define 단계가 어떻게 작동하는지는 디자인씽킹 프로세스에서 다뤄요.

참고 문헌

Jake Knapp, 《Sprint》(2016) - 5일 안에 문제를 정의하고 검증하는 실무 프레임워크예요.
Victor Papanek, 《Design for the Real World》(1971) - 진짜 문제를 보는 관점의 출발점이에요.

문제 정의가 디자인의 80%