통합 요약노트
Ch.11 문제 프레이밍
5 Whys, HMW 질문법, UX 법칙과의 연결
이 챕터의 내용
문제 vs 증상 — 5 Whys
근본 원인에 도달하는 강력한 도구 5 Whys와 Fishbone 다이어그램 — 문제 프레이밍의 첫걸음입니다.
증상을 고치면 문제는 반복됩니다
디자인 프로젝트에서 가장 흔한 실수는 증상(symptom)을 문제(problem)로 착각하는 것입니다. 증상은 눈에 보이는 결과이고, 문제는 그 결과를 만들어내는 숨겨진 원인입니다. 증상만 치료하면 같은 문제가 다른 형태로 반복됩니다.
증상 = 관찰 가능한 결과 | 문제 = 증상을 발생시키는 구조적 원인
- 증상(결과)과 문제(원인)를 구분해야 올바른 해결책을 찾을 수 있다
- 5 Whys: '왜?'를 반복해 표면 증상에서 근본 원인으로 내려가는 기법
- Fishbone: 원인을 카테고리별로 분류해 빠짐없이 탐색하는 시각화 도구
- 최선 조합: Fishbone(넓이) + 5 Whys(깊이)로 근본 원인 완전 포착
- Hick's Law 연결: 근본 원인 해결이 UX 법칙 위반도 함께 해소한다
HMW 질문법과 리프레이밍
IDEO가 만든 강력한 프레이밍 도구 HMW(How Might We) — 문제를 기회로 전환하는 질문 기술입니다.
How Might We — 세 단어에 담긴 철학
How Might We(HMW)는 IDEO에서 체계화한 디자인 씽킹의 핵심 도구입니다. 문제를 '해결해야 할 과제'에서 '탐색할 기회'로 전환합니다. 세 단어 각각에 중요한 철학이 담겨 있습니다.
HMW 작성 공식
- HMW = How(낙관) + Might(탐색) + We(협업)의 철학이 담긴 질문 형식
- 좋은 HMW: 적절한 범위 + 사용자 중심 + 해결책 미포함
- HMW 공식: HMW + [대상] + [원하는 결과] + [맥락/제약]
- 리프레이밍: 제거, 반전, 분해, 유추, 극단 — 5가지 관점 전환
- 제약 조건을 명시하면 HMW가 실행 가능한 수준으로 구체화된다
기회 평가 — RICE/ICE
기회 평가의 표준 프레임워크 RICE와 ICE, 그리고 기회를 구조화하는 Opportunity Solution Tree를 배웁니다.
네 가지 축으로 기회를 수치화합니다
RICE는 Intercom이 개발한 우선순위 결정 프레임워크입니다. 주관적 감에 의존하지 않고, 네 가지 축(Reach, Impact, Confidence, Effort)을 수치화하여 기회를 비교합니다.
RICE Score = (Reach × Impact × Confidence) / Effort
- RICE = (Reach × Impact × Confidence) / Effort — 정밀한 기회 평가
- Effort를 분모에 놓아 ROI 관점의 우선순위를 산출한다
- ICE = (Impact + Confidence + Ease) / 3 — 빠른 전술적 판단에 적합
- Opportunity Solution Tree: Outcome → Opportunity → Solution → Experiment 구조
- RICE/ICE는 OST의 Opportunity 레벨에서 우선순위를 매기는 데 활용
핵심 용어 모음
방향
5 Whys = 수직(깊이) / Fishbone = 수평(넓이)
적합 상황
5 Whys = 원인이 선형 체인일 때 / Fishbone = 복합 원인일 때
결과물
5 Whys = 단일 근본 원인 / Fishbone = 카테고리별 원인 맵
최선 조합
Fishbone으로 넓게 펼친 뒤, 각 가지에서 5 Whys로 깊이 파기
How (어떻게)
해결책이 존재한다는 낙관적 전제. '할 수 없다'가 아닌 '방법을 찾자'의 태도
Might (~할 수 있을까)
가능성의 탐색. '해야 한다(must)'가 아닌 '해볼 수 있을까(might)' — 실패해도 괜찮다는 안전감
We (우리가)
팀 전체의 협업. 개인의 아이디어가 아닌 집단의 창의성을 끌어내는 초대
Reach (도달 범위)
일정 기간 내 영향받는 사용자 수. 예: '분기당 10,000명이 이 기능을 사용'
Impact (영향도)
개별 사용자에게 미치는 영향 크기. 3(massive)~0.25(minimal) 척도
Confidence (확신도)
추정의 신뢰도. 100%(데이터 기반)~50%(직감). 80% 이하면 검증 필요 신호
Effort (노력)
인-월(person-month) 단위. 디자인+개발+QA 전체 투입 공수
비교 정리
| 항목 | 좋은 HMW | 나쁜 HMW |
|---|---|---|
| 범위 | 신규 사용자가 첫 주에 3번 이상 재방문하게 할 수 있을까? | 모든 사용자의 리텐션을 높일 수 있을까? (너무 넓음) |
| 해결책 포함 여부 | 사용자가 결제 과정에서 이탈하지 않게 할 수 있을까? | 결제 버튼을 빨간색으로 바꿔 전환율을 높일 수 있을까? (답이 질문 안에 있음) |
| 사용자 중심 | 초보 사용자가 복잡한 설정 없이 첫 작업을 완료하게 할 수 있을까? | 기술 부채를 줄이면서 온보딩을 개선할 수 있을까? (기술 관점) |
| 항목 | RICE | ICE |
|---|---|---|
| 요소 | Reach × Impact × Confidence / Effort (4개) | Impact + Confidence + Ease (3개) |
| 정밀도 | Reach를 실제 사용자 수로 측정 → 데이터 기반 정밀 평가 | 1~10 주관적 척도 → 빠르지만 평가자마다 편차 큼 |
| 속도 | 데이터 수집 필요 → 평가에 시간 소요 | 즉석에서 팀원이 점수 매기기 가능 → 5분 내 완료 |
| 적합 상황 | 로드맵 분기 계획, 대규모 기능 우선순위 | 스프린트 백로그, 그로스 실험 우선순위 |
퀴즈와 인터랙션으로 더 깊이 학습하세요
play_circle인터랙티브 코스 시작하기