제품 가설을 검증해야 할 때 /product-discovery가 구조화된 조사를 실행해 근거를 가지고 출시하게 합니다. — Claude Skill

---

title: 섹션 구성

1. 리서치 방법 (research)

영향도: 매우 높음 설명: 사용자 인터뷰 기법, 설문 설계, 리서치 운영. 모든 발견 작업의 기반입니다.

2. 문제 발견 (discovery)

영향도: 매우 높음 설명: 문제 식별, 검증, 해야 할 일(JTBD) 프레임워크. 해결할 가치가 있는 문제를 찾습니다.

3. 분석 및 종합 (analysis)

영향도: 높음 설명: 세그먼트화, 경쟁 분석, 기회 규모 산정, 인사이트 종합. 데이터를 이해 가능한 판단으로 바꿉니다.

4. 테스트 및 검증 (testing)

영향도: 높음 설명: 프로토타입 테스트, 사용성 테스트, 실험 설계. 만들기 전에 솔루션을 검증합니다.

---

title: 경쟁 분석 impact: HIGH tags: analysis, competitive, market, positioning

경쟁 분석

영향도: 높음

경쟁사를 깊이 이해하세요. 베끼기 위해서가 아니라 차별화하기 위해서입니다. 목표는 기능을 맞추는 것이 아니라 빈틈을 찾는 것입니다.

경쟁 구도

경쟁사의 유형

경쟁 구도 매핑

                    높은 인지도
                          │
        직접 ─────────────┼──────────── 간접
        경쟁사             │            경쟁사
        (같은 솔루션)       │            (다른 솔루션)
                          │
    ──────────────────────┼────────────────────────
                          │
        대체 ─────────────┼──────────── 관성
        접근               │            (비소비)
                          │
                    낮은 인지도

경쟁 리서치 프레임워크

조사할 내용

경쟁사 프로필 템플릿

┌─────────────────────────────────────────────────────────┐
│ 경쟁사: [이름]                                          │
│ 웹사이트: [URL]                                         │
│ 설립: [연도]      투자: [금액]      직원 수: [숫자]       │
├─────────────────────────────────────────────────────────┤
│ 포지셔닝                                                │
│ 태그라인: [상대의 제목]                                 │
│ 대상: [서비스 대상]                                     │
│ 카테고리: [스스로를 설명하는 방식]                       │
├─────────────────────────────────────────────────────────┤
│ 제품                                                    │
│ 핵심 기능: [주요 역량]                                  │
│ 가격: [모델과 가격대]                                   │
│ 연동: [주요 플랫폼]                                     │
├─────────────────────────────────────────────────────────┤
│ 강점                                                    │
│ • [강점 1]                                              │
│ • [강점 2]                                              │
├─────────────────────────────────────────────────────────┤
│ 약점                                                    │
│ • [약점 1]                                              │
│ • [약점 2]                                              │
├─────────────────────────────────────────────────────────┤
│ 신호                                                    │
│ 최근 움직임: [제품 출시, 투자, 채용]                     │
│ 리뷰 정서: [고객이 말하는 내용]                          │
└─────────────────────────────────────────────────────────┘

기능 비교 매트릭스

기능 매트릭스 만들기

사용 방법:

• 초록색 칸: 우리의 우위
• 빨간색 칸: 상대의 우위
• 흰색 칸: 기본 기대치

포지셔닝 분석

경쟁 포지셔닝 지도

                    엔터프라이즈
                        │
                        │
                        │         [경쟁사 C]
    복잡함 ─────────────┼──────────────────── 단순함
                        │
              [경쟁사 A]│
                        │    [우리]
                        │
                    스타트업/중소기업

포지셔닝 질문:

• 고객에게 가장 중요한 축은 무엇인가?
• 경쟁사는 어디에 몰려 있는가?
• 비어 있는 공간은 어디인가?
• 우리가 고유한 위치를 차지할 수 있는가?

승패 분석

이기는 이유와 지는 이유 추적

찾아야 할 패턴:

• 어떤 경쟁사를 상대로 가장 많이 이기는가?
• 수주한 거래에서 어떤 기능이 중요한가?
• 왜 지는가? 고칠 수 있는가?
• 추구하지 말아야 할 거래가 있는가?

이탈 고객 리서치

경쟁사로 떠난 고객 인터뷰

질문:
"대안을 찾기 시작한 계기는 무엇이었나요?"
"어떤 선택지를 검토했나요?"
"[경쟁사]를 선택하게 만든 요인은 무엇이었나요?"
"[경쟁사]가 더 잘하는 것은 무엇인가요?"
"저희 제품에서 그리운 점은 무엇인가요?"
"다시 돌아오려면 무엇이 필요할까요?"

이탈 분석 프레임워크

경쟁 정보 출처

공개 출처

- 웹사이트와 제품(무료 체험 사용)
- G2, Capterra 리뷰
- LinkedIn(인원 규모, 채용 공고)
- Crunchbase(투자, 투자자)
- 보도자료, 뉴스
- 콘퍼런스 발표, 팟캐스트
- 소셜 미디어 존재감
- SEO/콘텐츠 분석

리서치 출처

- 승패 인터뷰
- 고객 인터뷰(그들이 함께 검토한 다른 선택지)
- 영업팀 피드백
- 업계 애널리스트 보고서
- 경쟁 제품 사용자 테스트

경쟁 모니터링

지속적으로 추적:
- 채용 공고(무엇을 만들고 있는가)
- 가격 변경
- 신규 기능 발표
- 투자 라운드
- 리더십 변화
- 고객 리뷰(새로운 주제)

배틀카드 템플릿

영업과 포지셔닝용

┌─────────────────────────────────────────────────────────┐
│ 배틀카드: vs [경쟁사]                                  │
├─────────────────────────────────────────────────────────┤
│ 한 줄 요약                                              │
│ [그들이 누구이며 핵심 차이가 무엇인지 한 문장]          │
├─────────────────────────────────────────────────────────┤
│ 고객이 그들을 선택하는 이유                             │
│ • [이유 1]                                              │
│ • [이유 2]                                              │
├─────────────────────────────────────────────────────────┤
│ 고객이 우리를 선택하는 이유                             │
│ • [이유 1]                                              │
│ • [이유 2]                                              │
├─────────────────────────────────────────────────────────┤
│ 흔한 반론과 답변                                        │
│ "그들은 기능 X가 있어요"                                │
│ → [답변]                                                │
│                                                         │
│ "그들은 더 오래된 회사예요"                             │
│ → [답변]                                                │
├─────────────────────────────────────────────────────────┤
│ 잠재 고객에게 물어볼 핵심 질문                          │
│ • [그들의 약점을 드러내는 질문]                         │
│ • [우리의 강점을 부각하는 질문]                         │
├─────────────────────────────────────────────────────────┤
│ 지뢰 지점(그들이 우리에 대해 퍼뜨리는 FUD)              │
│ • [그들이 우리에 대해 말하는 내용]                      │
│ → [진실과 답변]                                         │
└─────────────────────────────────────────────────────────┘

경쟁 전략 선택지

경쟁하는 방법

경쟁 분석 실수

흔한 오류

1. 기능 비교만 함
   → 기능은 포지셔닝, 경험, 신뢰를 담아내지 못합니다

2. 간접 경쟁을 무시함
   → 스프레드시트와 "아무것도 하지 않기"도 경쟁사입니다

3. 정적인 분석
   → 시장은 변합니다. 분기마다 새로 고치세요

4. 승자를 베낌
   → 경쟁사를 따라가면 절대 앞서갈 수 없습니다

5. 분석 마비
   → 전부 알려고 하지 말고 행동할 만큼만 알아야 합니다

안티패턴

• 기능 추격 — 경쟁사에 있다는 이유로 기능 추가
• 경쟁사 집착 — 고객보다 경쟁사에 더 많은 시간을 씀
• 비소비 무시 — 가장 큰 경쟁자는 종종 "아무것도 하지 않기"입니다
• 정적인 배틀카드 — 절대 업데이트되지 않는 경쟁 정보
• 전해 들은 정보만 사용 — 영업을 통해서만 경쟁사 이야기를 들음
• 포지셔닝 복제 — 다르게 보이기보다 상대의 더 나쁜 버전이 됨

---

title: 기회 규모 산정 및 우선순위화 impact: HIGH tags: analysis, opportunity, prioritization, roadmap

기회 규모 산정 및 우선순위화

영향도: 높음

모든 기회가 같은 가치를 갖는 것은 아닙니다. 규모 산정과 우선순위화는 서비스를 제공할 가치가 있는 시장에서 해결할 가치가 있는 문제에 집중하게 해줍니다.

시장 규모 산정 기본

TAM, SAM, SOM

┌─────────────────────────────────────────────────────────┐
│                         TAM                             │
│                 전체 주소 지정 가능 시장                │
│              "잠재적으로 구매할 수 있는 모든 사람"      │
│                                                         │
│    ┌───────────────────────────────────────────┐       │
│    │                   SAM                     │       │
│    │             서비스 가능 주소 지정 시장     │       │
│    │             "현실적으로 도달 가능한 대상"  │       │
│    │                                           │       │
│    │    ┌───────────────────────────────┐     │       │
│    │    │             SOM               │     │       │
│    │    │        서비스 가능 확보 시장   │     │       │
│    │    │          "우리가 확보할 수 있는 몫" │       │
│    │    └───────────────────────────────┘     │       │
│    └───────────────────────────────────────────┘       │
└─────────────────────────────────────────────────────────┘

규모 산정 접근법

상향식 규모 산정(가장 유용)

공식:

시장 규모 = 목표 고객 수 x 평균 계약 가치 x 구매 빈도

예:
- 미국의 시리즈 A-C 스타트업 50,000개
- x 30%가 문제를 가짐(15,000개)
- x 50%가 구매를 검토함(7,500개)
- x ACV 5,000달러
- x 연 1회 구매
= SOM 3,750만 달러

세그먼트로 정교화:

기회 점수화 프레임워크

RICE 점수화

점수 = (도달 범위 x 영향 x 확신도) / 노력

예시:

기회-솔루션 트리

문제를 가능한 솔루션에 매핑

목표: 활성화율 증가

├── 기회: 사용자가 가치를 이해하지 못함
│   ├── 솔루션: 상호작용형 온보딩
│   ├── 솔루션: 가치 중심의 빈 상태
│   └── 솔루션: 개인화된 설정 흐름
│
├── 기회: 설정이 너무 복잡함
│   ├── 솔루션: 원클릭 템플릿
│   ├── 솔루션: 경쟁사에서 가져오기
│   └── 솔루션: AI 지원 설정
│
└── 기회: 사용자가 "아하 순간"에 도달하지 못함
    ├── 솔루션: 안내형 첫 작업
    ├── 솔루션: 실험해 볼 샘플 데이터
    └── 솔루션: 성공 마일스톤 축하

우선순위 매트릭스

영향 vs 노력(2x2)

높은 영향
    │
    │   빠른 성과       │    큰 베팅
    │   (지금 실행)     │    (신중히 계획)
    │                   │
────┼───────────────────┼───────────────────
    │                   │
    │   보완 작업       │    비용 함정
    │   (쉬우면 실행)   │    (피하기)
    │                   │
    └───────────────────┴──────────── 높은 노력

ICE 점수화(단순화)

점수 = (영향 + 확신도 + 용이성) / 3

고객 가치 vs 비즈니스 가치

두 관점의 균형

우선순위화 전 검증

근거 수준

노력별 최소 근거

포트폴리오 접근

베팅의 균형

70/20/10 규칙:

70% → 핵심 개선
      낮은 위험, 확인된 가치
      고객이 요청하는 기능
      최적화, 부채 감소

20% → 인접 베팅
      중간 위험, 가능성 높은 가치
      기존 사용자를 위한 새로운 사용 사례
      확장 기능

10% → 전환적 베팅
      높은 위험, 높은 잠재력
      새로운 시장, 새로운 제품
      큰 승부수

거절하기

우선순위에서 제외하는 프레임워크

거절해야 할 때:

- 기회 점수가 너무 낮음
- 목표 세그먼트에 맞지 않음
- 전략과 충돌함
- 더 나은 대안이 있음
- 근거가 약함
- 시기가 맞지 않음

거절하는 방법:

1. 요청을 인정합니다
2. 판단 근거를 설명합니다
3. 지금 하고 있는 일을 공유합니다
4. 상황이 바뀌면 다시 볼 여지를 남깁니다

예:
"여러 고객에게서 이 요청을 들었습니다. 지금은 [근거/전략] 때문에
[X]에 집중하고 있습니다. 이 항목은 추적하고 있으며 더 많은
데이터가 생기는 3분기에 다시 검토하겠습니다."

기회 추적

기회 백로그 템플릿

안티패턴

• HiPPO 우선순위화 — 최고 연봉자의 의견이 이김
• 시끄러운 바퀴 효과 — 가장 목소리 큰 고객이 우선순위를 가져감
• 최신성 편향 — 가장 최근에 들은 요청이 가장 중요해 보임
• 기능 공장 — 결과를 검증하지 않고 계속 구축
• 분석 마비 — 끝없이 점수만 매기고 만들지 않음
• 단일 지표 독재 — 한 요소에 과도하게 의존
• 전략 적합성 무시 — 복리 효과가 없는 것을 만듦
• 매몰 비용 오류 — 시작했다는 이유로 계속함

---

title: 고객 세그먼트 리서치 impact: HIGH tags: analysis, segmentation, personas, targeting

고객 세그먼트 리서치

영향도: 높음

모든 고객이 같은 것은 아닙니다. 세그먼트화는 어떤 고객을 우선해야 하는지, 그리고 고객별로 어떻게 다르게 서비스를 제공해야 하는지 드러냅니다.

세그먼트 vs 페르소나

세그먼트화 접근법

행동 기반 세그먼트화(가장 가치 있음)

고객이 무엇을 하는지로 세그먼트화:
- 사용 패턴(고급 사용자 vs 가벼운 사용자)
- 구매 행동(빈도, 가치)
- 기능 도입(어떤 역량을 쓰는가)
- 참여 수준(활성 vs 휴면)
- 업무 흐름(제품을 어떻게 쓰는가)

니즈 기반 세그먼트화

고객에게 무엇이 필요한지로 세그먼트화:
- 주요 해야 할 일
- 필수 기능 vs 있으면 좋은 기능
- 성공 지표("작동한다"는 것이 무엇을 의미하는가?)
- 고통 강도(얼마나 긴급한가)

기업 특성 기반 세그먼트화(B2B)

회사 특성으로 세그먼트화:
- 규모(직원 수, 매출)
- 산업/버티컬
- 단계(스타트업, 성장, 엔터프라이즈)
- 지역
- 기술 스택

인구통계 기반 세그먼트화(B2C)

사람 특성으로 세그먼트화:
- 나이, 소득, 위치
- 역할, 직급
- 경험 수준
- 회사 유형(관련 있는 경우)

리서치로 세그먼트 만들기

1단계: 데이터 수집

출처:
- 사용자 인터뷰(정성)
- 설문 응답(정량)
- 제품 분석(행동)
- CRM 데이터(기업 특성)
- 지원 티켓(고통 지점)

2단계: 패턴 식별

다음 주변의 군집을 찾습니다:
- 비슷한 문제/해야 할 일
- 비슷한 행동
- 비슷한 결과
- 비슷한 반론

인터뷰 메모 → 친화도 매핑 → 패턴 인식

3단계: 세그먼트 정의

4단계: 세그먼트 검증

검증 기준:
- 식별 가능: 이들을 찾을 수 있는가?
- 충분한 규모: 중요할 만큼 큰가?
- 접근 가능: 도달할 수 있는가?
- 구별 가능: 다른 집단과 뚜렷이 다른가?
- 실행 가능: 다르게 서비스할 수 있는가?

세그먼트 우선순위 매트릭스

각 세그먼트 점수화

우선순위화 예시

페르소나 개발

세그먼트에서 페르소나로

세그먼트: "스타트업(직원 20-100명)"

페르소나: "성장 중인 사라"
- 역할: 엔지니어링 책임자
- 맥락: 시리즈 A 스타트업, 빠르게 성장 중
- 주요 해야 할 일: 품질을 유지하면서 기능 출시
- 핵심 고통: 팀이 커지면서 기술 부채가 쌓임
- 성공 지표: 사고 없는 배포 빈도
- 인용문: "속도를 내려고 멈출 수는 없어요."

페르소나 템플릿

┌─────────────────────────────────────────────────────────┐
│ 페르소나 이름: [설명형 이름]                            │
├─────────────────────────────────────────────────────────┤
│ 역할: [직함]                                            │
│ 맥락: [회사 유형, 규모, 단계]                           │
├─────────────────────────────────────────────────────────┤
│ 목표:                                                   │
│ • [주요 목표]                                           │
│ • [보조 목표]                                           │
├─────────────────────────────────────────────────────────┤
│ 불만:                                                   │
│ • [고통 지점 1]                                         │
│ • [고통 지점 2]                                         │
├─────────────────────────────────────────────────────────┤
│ 행동:                                                   │
│ • [일하는 방식]                                         │
│ • [구매하는 방식]                                       │
│ • [정보를 얻는 곳]                                      │
├─────────────────────────────────────────────────────────┤
│ 인용문: "[인터뷰에서 나온 대표 발언]"                    │
└─────────────────────────────────────────────────────────┘

세그먼트별 리서치

세그먼트 단계별 리서치 질문

새 세그먼트(탐색 중):
- 이들은 어떤 해야 할 일을 위해 제품을 고용하는가?
- 오늘은 어떤 대안을 쓰는가?
- 무엇이 있으면 전환하는가?
- 어떻게 구매하는가? 누가 관여하는가?

기존 세그먼트(심화 중):
- 어떤 기능을 가장 많이/가장 적게 쓰는가?
- 어디에서 막히는가?
- 무엇이 있으면 사용을 확장하는가?
- 실제 업무 흐름은 무엇인가?

위험 세그먼트(유지 중):
- 처음에는 왜 구매했는가?
- 무엇이 바뀌었는가?
- 다시 참여시키려면 무엇이 필요한가?
- 다른 세그먼트를 위해 무엇을 배울 수 있는가?

다중 세그먼트 전략

교두보 → 확장

1단계: 교두보
처음에는 장악할 세그먼트 하나를 선택합니다.
기준:
- 가장 쉽게 도달 가능
- 가장 빠른 영업 주기
- 초기 제품에 가장 관대함
- 학습에 가장 좋음

2단계: 인접 확장
다음 조건의 세그먼트를 추가합니다:
- 비슷한 해야 할 일을 공유
- 같은 핵심 제품을 사용할 수 있음
- 큰 방향 전환이 필요 없음
- 기존 평판 위에 쌓을 수 있음

3단계: 시장 커버리지
다음 조건의 더 큰 세그먼트로 확장합니다:
- 제품 성숙도가 필요함
- 사례 연구/증거가 필요함
- 영업 주기가 더 김

여러 세그먼트를 서비스해야 할 때

예, 다음 조건이면:
- 핵심 제품이 둘 다 서비스함
- 한계 비용이 낮음
- 세그먼트가 충돌하지 않음
- 리소스가 있음

아니요, 다음 조건이면:
- 서로 다른 제품이 필요함
- 세그먼트의 니즈가 상충함
- 팀이 너무 얇게 분산됨
- 한 세그먼트가 명확히 더 좋음

세그먼트화 안티패턴

인구통계만으로 세그먼트화

나쁨: "소규모 비즈니스"(너무 넓음. 무엇을 공유하는가?)
좋음: "재고 관리에 어려움을 겪는 직원 10-50명의 성장 중인 전자상거래 비즈니스"

너무 많은 세그먼트

나쁨: 미묘한 차이가 있는 페르소나 12개
좋음: 명확히 구별되는 세그먼트 3-4개

정적인 세그먼트

나쁨: "2년 전에 페르소나를 정의했습니다"
좋음: 세그먼트 적합성과 행동 변화를 분기별로 검토

현실이 아니라 바람으로 세그먼트화

나쁨: "엔터프라이즈는 훌륭한 고객이 될 거야"
      (하지만 실제로 팔아 본 적 없음)
좋음: 실제 고객 데이터에 기반한 세그먼트

세그먼트 리서치 도구

안티패턴

• 편의에 따른 세그먼트화 — 중요한 데이터가 아니라 이미 가진 데이터를 사용
• 페르소나 연극 — 아무도 쓰지 않는 보기 좋은 문서
• 부정적 세그먼트 무시 — 맞지 않는 고객을 명시적으로 낮은 우선순위로 두지 않음
• 일률적 접근 — 모든 세그먼트에 같은 메시지/제품 적용
• 세그먼트 증식 — 기존 세그먼트를 검증하지 않고 새 세그먼트 생성
• 인구통계 집착 — 행동/니즈보다 나이/규모를 더 중시

---

title: 리서치 종합 및 인사이트 도출 impact: HIGH tags: analysis, synthesis, insights, research-ops

리서치 종합 및 인사이트 도출

영향도: 높음

가공되지 않은 리서치는 데이터일 뿐입니다. 종합은 관찰을 의사결정을 움직이는 인사이트로 바꿉니다.

종합 프로세스

수집 → 정리 → 분석 → 종합 → 전달

관찰 → 주제 → 패턴 → 인사이트 → 권고안

관찰에서 인사이트로

친화도 매핑

단계별 프로세스

1. 준비
   - 각 관찰을 포스트잇에 인쇄하거나 적습니다
   - 포스트잇 하나에 관찰 하나만 담습니다
   - 추적 가능하도록 참가자 ID를 포함합니다

2. 군집화
   - 비슷한 관찰을 함께 묶습니다
   - 범주를 억지로 만들지 말고 자연스럽게 드러나게 합니다
   - 진행하면서 포스트잇을 옮깁니다

3. 라벨링
   - 각 군집에 주제 이름을 붙입니다
   - 주제는 단순 설명이 아니라 본질을 담아야 합니다

4. 정리
   - 관계에 따라 군집을 배치합니다
   - 상위 주제를 찾습니다
   - 이상치를 기록합니다(버리지 않음)

5. 문서화
   - 벽을 사진으로 남깁니다
   - 디지털 도구로 옮깁니다(Miro, FigJam)
   - 각 군집의 개수를 기록합니다

친화도 지도 예시

┌─────────────────────────────────────────────────────────┐
│                    리서치 결과                          │
├─────────────┬──────────────┬─────────────┬─────────────┤
│   신뢰      │   온보딩     │    가치     │  업무 흐름  │
│   문제      │   마찰       │    명확성   │  빈틈       │
├─────────────┼──────────────┼─────────────┼─────────────┤
│ • "보안이   │ • "단계가    │ • "무엇을   │ • "도구를   │
│   걱정돼요" │   너무 많음" │   하는지    │   오가야    │
│ • "누가     │ • "어디서    │   모르겠음" │   함"       │
│   접근할 수 │   시작할지   │ • "왜 써야  │ • "수동     │
│   있나요?"  │   몰랐음"    │   하나요?"  │   복사/붙여 │
│ • "내       │ • "선택지가  │ • "가격이   │   넣기"     │
│   데이터를  │   너무 많아  │   불명확함" │             │
│   지울 수   │   부담됨"    │             │             │
│   있나요?"  │              │             │             │
│             │              │             │             │
│ [메모 5개]  │ [메모 8개]   │ [메모 6개]  │ [메모 4개]  │
└─────────────┴──────────────┴─────────────┴─────────────┘

인사이트 프레임워크

인사이트 = 관찰 + 해석 + 함의

관찰: 무엇을 보고 들었는가?
"사용자 10명 중 7명이 상단 내비게이션에서 설정을 찾으려 했습니다"

해석: 이것은 무엇을 의미하는가?
"사용자는 자신이 쓰는 다른 앱을 바탕으로 계정 수준의 작업이
 헤더에 있다고 보는 멘탈 모델을 갖고 있습니다"

함의: 왜 중요한가?
"사이드바 기반 설정은 마찰을 만들고 사용자가 길을 잃었다고
 느끼게 하며, 활성화에 영향을 줍니다"

인사이트 품질 체크리스트

좋은 인사이트는 다음과 같습니다:

• 실행 가능 — 실제로 조치를 취할 수 있음
• 뻔하지 않음 — 이미 알고 있던 사실이 아님
• 구체적 — 명확하고 구체적임
• 근거 기반 — 증거가 뒷받침함
• 생성적 — 솔루션을 떠올리게 함

리서치 저장소

재사용을 위한 결과 정리

/research
├── /projects
│   ├── /2024-q1-onboarding-study
│   │   ├── research-plan.md
│   │   ├── interview-notes/
│   │   ├── synthesis.md
│   │   └── presentation.pdf
│   └── /2024-q2-pricing-research
│       └── ...
├── /insights
│   ├── navigation.md
│   ├── pricing-perception.md
│   └── trust-barriers.md
├── /personas
│   └── personas.md
└── /templates
    └── interview-guide.md

인사이트 문서 템플릿

# 인사이트: [제목]

## 요약
[한 문장 인사이트]

## 근거
- 연구: [리서치 프로젝트 링크]
- 참가자: [대상/인원]
- 핵심 인용:
  - "[인용문 1]" — P3
  - "[인용문 2]" — P7

## 분석
[이것이 제품에 의미하는 바는 무엇인가?]

## 권고안
- [조치 1]
- [조치 2]

## 관련 인사이트
- [관련 인사이트 링크]

## 상태
- 발견일: [날짜]
- 마지막 검증일: [날짜]
- 취한 조치: [없음/진행 중/해결됨]

종합 세션

팀 종합 진행

참가자: 제품 관리자, 디자이너, 엔지니어, 선택: 리서처, 이해관계자

준비(세션 전):
- 모든 참가자가 원본 메모를 검토
- 각자가 눈에 띄는 관찰 5-10개 표시
- 벽 또는 디지털 보드 준비

세션 구조(2-3시간):

1. 관찰 공유(30분)
   - 각자가 주요 관찰을 공유
   - 아직 토론하지 않고 기록만 함

2. 군집화와 주제화(45분)
   - 비슷한 관찰을 묶음
   - 군집에 이름을 붙임
   - 의견 차이를 논의

3. 주제 우선순위화(30분)
   - 어떤 주제가 가장 영향이 큰가?
   - 어떤 주제가 근거가 가장 많은가?
   - 상위 5개를 강제로 순위화

4. 인사이트 도출(30분)
   - 상위 주제에 대해 인사이트를 명확히 표현
   - 관찰 → 해석 → 함의 사용

5. 함의 논의(30분)
   - 무엇을 다르게 해야 하는가?
   - 무엇이 더 많은 리서치를 필요로 하는가?
   - 누가 더 알아야 하는가?

결과 전달

리서치 공유 구조

1. 맥락(2분)
   - 왜 이 리서치를 했는가
   - 어떤 질문이 있었는가
   - 방법론 개요

2. 핵심 인사이트(10-15분)
   - 상위 인사이트 3-5개
   - 각 인사이트: 근거 + 함의
   - 대표 인용문/클립 포함

3. 상세 결과(선택, 10분)
   - 추가 주제
   - 놀라운 관찰
   - 세그먼트 차이

4. 권고안(5분)
   - 우선순위가 매겨진 조치
   - 더 탐색할 것
   - 중단/회피할 것

5. 논의(10분)
   - 질문
   - 반응
   - 다음 단계

한 페이지 요약 템플릿

┌─────────────────────────────────────────────────────────┐
│ 리서치 요약: [연구 이름]                                │
│ 날짜: [날짜]    참가자: [N]    방법: [유형]             │
├─────────────────────────────────────────────────────────┤
│ 리서치 질문                                             │
│ 1. [질문 1]                                             │
│ 2. [질문 2]                                             │
├─────────────────────────────────────────────────────────┤
│ 핵심 인사이트                                           │
│                                                         │
│ 1. [인사이트 제목]                                      │
│    근거: [간단한 뒷받침]                                │
│    함의: [의미]                                         │
│                                                         │
│ 2. [인사이트 제목]                                      │
│    근거: [간단한 뒷받침]                                │
│    함의: [의미]                                         │
│                                                         │
│ 3. [인사이트 제목]                                      │
│    근거: [간단한 뒷받침]                                │
│    함의: [의미]                                         │
├─────────────────────────────────────────────────────────┤
│ 권고안                                                  │
│ • [조치 1]                                              │
│ • [조치 2]                                              │
│ • [조치 3]                                              │
├─────────────────────────────────────────────────────────┤
│ 열린 질문                                               │
│ • [아직 배워야 할 것]                                   │
└─────────────────────────────────────────────────────────┘

종합 편향 피하기

흔한 편향

편향 완화 전술

- 여러 명이 함께 종합(혼자 하지 않음)
- 관찰 수를 집계(숫자는 편향을 줄임)
- 반대되는 근거 포함
- 불확실성 문서화
- 시간이 지난 뒤 재검토

리서치 운영

리서치 관행 구축

매주:
- 고객 인터뷰 2-3건
- 인사이트 저장소 업데이트
- 핵심 학습 공유

매월:
- 종합 세션
- 이해관계자 공유
- 리서치 백로그 우선순위화

분기별:
- 리서치 로드맵 검토
- 저장소 정리
- 방법 회고

안티패턴

• 인사이트 사재기 — 공유되지 않는 리서치
• 끝없는 분석 — 계속 종합만 하고 결론을 내지 않음
• 발표 전용 — 덱은 만들었지만 다시 참조하지 않음
• 리서처 한 명 의존 — 한 사람이 모든 것을 알고 있어 확장 불가
• 오래된 인사이트 — 2년 된 페르소나를 현재 사실로 취급
• 기능 검증만 함 — 무엇을 만들지뿐 아니라 왜 만드는지도 리서치해야 함
• 인용문 남용 — 이미 내린 결정을 지지하는 인용문만 골라냄

---

title: 해야 할 일(JTBD) 프레임워크 impact: CRITICAL tags: discovery, jtbd, jobs, motivation, customer-needs

해야 할 일(JTBD) 프레임워크

영향도: 매우 높음

사람들은 제품을 사지 않습니다. 어떤 일을 해내기 위해 제품을 고용합니다. 그 일을 이해하면 제품을 만들고 시장에 전달하는 방식이 완전히 달라집니다.

핵심 개념

"사람들은 4분의 1인치 드릴을 원하는 것이 아닙니다.
 4분의 1인치 구멍을 원하는 것입니다."
    — Theodore Levitt

"사실 그들은 그림을 걸고 싶어 합니다.
 사실 그들은 집처럼 느끼고 싶어 합니다."
    — JTBD 사고

전통적 관점 vs JTBD 관점

일의 해부

완전한 일 진술문

┌─────────────────────────────────────────────────────────┐
│                     완전한 일                           │
├─────────────────────────────────────────────────────────┤
│ [상황/맥락]일 때                                        │
│ 나는 [동기/행동]하고 싶다                               │
│ 그래서 [기대 결과]를 얻고 싶다                          │
├─────────────────────────────────────────────────────────┤
│ 기능적 일: 달성하려는 것                                │
│ 감정적 일: 느끼고 싶은 감정                             │
│ 사회적 일: 다른 사람에게 보이고 싶은 모습               │
└─────────────────────────────────────────────────────────┘

예시: 프로젝트 관리 도구

여러 이해관계자가 있는 복잡한 프로젝트를 이끌 때
나는 모든 사람의 진행 상황과 막힘 지점을 한곳에서 보고 싶다
그래서 프로젝트를 일정대로 유지하고 리더십에게 유능해 보이고 싶다

기능적 일: 팀원 전체의 프로젝트 상태 추적
감정적 일: 통제감을 느끼고 돌발 상황에 대한 불안 줄이기
사회적 일: 경영진에게 체계적이고 유능해 보이기

진전을 만드는 네 가지 힘

                    현재 상황의 압력
                    (현상 유지의 문제)
                              │
                              ▼
┌─────────────────────────────────────────────────────────┐
│                                                         │
│                         전환                            │
│                                                         │
└─────────────────────────────────────────────────────────┘
                              ▲
                              │
                    새 솔루션의 끌림
                    (새 방식의 매력)

──────────────────────────────────────────────────────────

                    새 솔루션에 대한 불안
                    (변화와 학습에 대한 두려움)
                              │
                              ▼
┌─────────────────────────────────────────────────────────┐
│                                                         │
│                      전환하지 않음                      │
│                                                         │
└─────────────────────────────────────────────────────────┘
                              ▲
                              │
                    현재의 습관
                    (현상 유지의 편안함)

전환이 일어나려면: 현재 상황의 압력 + 새 솔루션의 끌림 > 새 솔루션에 대한 불안 + 현재의 습관

JTBD 인터뷰 기법

타임라인

첫 생각에서 구매까지의 여정을 매핑합니다:

첫 생각 ─► 수동적 탐색 ─► 적극적 탐색 ─► 결정 ─► 구매 ─► 사용
   │             │              │            │        │       │
   ▼             ▼              ▼            ▼        ▼       ▼
"무엇이       "어디에서       "무엇을     "왜 이    "어떻게  "잘
 계기였나요?"  찾아봤나요?"    비교했나요?" 하나인가요?" 샀나요?" 작동하나요?"

타임라인 인터뷰 질문

첫 생각:
"[솔루션]을 처음 생각하기 시작했을 때로 돌아가 보겠습니다."
"그 순간 삶이나 업무에서 무슨 일이 일어나고 있었나요?"
"찾아보기 시작하도록 밀어붙인 계기는 무엇이었나요?"

수동적 탐색:
"그다음에는 무엇을 했나요?"
"솔루션을 어디에서 찾아봤나요?"
"이 문제에 대해 누구와 이야기했나요?"

적극적 탐색:
"언제부터 진지해졌나요?"
"어떤 선택지를 검토했나요?"
"그것들을 어떻게 평가했나요?"

결정:
"[솔루션]을 선택하게 만든 요인은 무엇이었나요?"
"무엇이 거의 막을 뻔했나요?"
"결정에 또 누가 관여했나요?"

사용:
"지금은 어떻게 되고 있나요?"
"무엇이 나아졌나요? 무엇은 아닌가요?"
"다시 선택해도 같은 결정을 하겠나요?"

일 매핑

주요 일을 단계로 나누기

예시: 일 = "고객 프레젠테이션 준비"

경쟁 솔루션(진짜 경쟁)

진짜 경쟁사는 비슷한 제품이 아니라 대안입니다

일: "내 업계에 대해 계속 정보를 얻기"

전통적 경쟁사:
- 업계 간행물
- 업계 뉴스레터

진짜 경쟁사(대안):
- Twitter/X
- LinkedIn 피드
- 출퇴근 중 팟캐스트
- Slack 커뮤니티
- 아무것도 하지 않기(놓치는 기쁨, JOMO)

JTBD를 통한 경쟁 분석

결과 진술문

기능이 아니라 결과를 작성

형식: [Direction] + [Metric] + [Object of Control] + [Context]

좋은 결과 진술문

"관련 정보를 찾는 데 걸리는 시간을 최소화"
"중요한 업데이트를 놓칠 가능성을 줄임"
"동료와 인사이트를 공유하는 능력을 높임"
"트렌드를 따라가는 데 드는 노력을 최소화"

나쁜 결과 진술문

"사용하기 쉬움" (모호함)
"좋은 기능이 있음" (결과가 아님)
"사용자가 좋아함" (구체적이지 않음)
"빠름" (측정할 수 없음)

기회 점수화

각 결과를 중요도와 만족도로 평가

기회 = 중요도 + max(중요도 - 만족도, 0)

해석:

• 점수 > 12: 충분히 서비스되지 않는 기회(금광)
• 점수 10-12: 탐색할 가치가 있는 기회
• 점수 < 10: 충분히 서비스되고 있거나 중요하지 않음

산업별 JTBD 예시

B2B 소프트웨어

일: "새 팀원을 온보딩해야 할 때, 보안 위험을 만들지 않으면서
      빠르게 생산성을 낼 수 있도록 필요한 모든 것에 대한
      접근 권한을 주고 싶다."

경쟁사: 수동 프로세스, IT 티켓, 스프레드시트, 기존 IAM 도구

소비자 앱

일: "10분의 빈 시간이 있을 때, 가치 있는 것을 배우고 있다는
      느낌을 받아 생산적으로 느끼고 공유할 흥미로운 이야기를
      갖고 싶다."

경쟁사: 팟캐스트, Twitter, 뉴스 앱, YouTube, 그냥 쉬기

B2B 서비스

일: "연간 예산을 계획할 때, 낭비를 줄이고 신규 투자를
      정당화할 수 있도록 실제로 소프트웨어에 얼마를 쓰고
      있는지 이해하고 싶다."

경쟁사: 재무팀 스프레드시트, 구매 도구, 연 1회 처리

흔한 JTBD 실수

실수 1: 일이 너무 넓음

나쁨: "팀과 소통하기"
좋음: "의사결정에 대한 빠른 피드백이 필요할 때, 깊은 업무를
       방해하지 않고 관련 사람들의 의견을 받기"

실수 2: 일이 너무 좁음

나쁨: "Slack 메시지 보내기"
좋음: "동료에게 빠르고 비공식적인 답을 얻기"

실수 3: 일과 작업을 혼동

작업: "보고서 만들기"
일: "지속적인 예산을 확보하기 위해 이해관계자에게 가치를 증명하기"

실수 4: 감정적/사회적 일을 무시

기능만 봄: "내 캘린더 관리"
완전함: "내 시간을 통제하고 있다고 느끼고 다른 사람에게 신뢰할 만해 보이기"

안티패턴

• 기능 우선 사고 — "X를 만들 수 있다"가 아니라 "어떤 일이 존재하는가"에서 시작해야 함
• 인구통계 세그먼트화 — "밀레니얼은..."이 아니라 "[일]을 하려는 사람은..."이라고 봐야 함
• 비소비 무시 — 왜 사람들이 아무것도 하지 않는지 고려하지 않음
• 너무 추상적인 일 — "삶을 더 좋게 만들기"는 일이 아님
• 타임라인 생략 — 구매까지의 여정을 이해하지 않음
• 기능적 일만 봄 — 감정적, 사회적 차원을 놓침

---

title: 문제 발견 및 검증 impact: CRITICAL tags: discovery, validation, problems, product-market-fit

문제 발견 및 검증

영향도: 매우 높음

제품에서 가장 비싼 실수는 아무도 필요로 하지 않는 것을 만드는 것입니다. 문제 검증은 존재하지 않는 문제에 대한 솔루션을 만드는 일을 막아줍니다.

문제-솔루션 적합성

┌─────────────────────────────────────────────────────────┐
│                    제품 성공                            │
│                                                         │
│   문제-솔루션 적합성      →      제품-시장 적합성        │
│   (우리가 실제 문제를            (이것을 수익성 있게     │
│    해결하고 있는가?)              확장할 수 있는가?)     │
│                                                         │
│   발견 단계                 →      성장 단계             │
└─────────────────────────────────────────────────────────┘

대부분의 스타트업은 문제-솔루션 적합성에서 실패합니다.
그들은 다음과 같은 문제를 위한 솔루션을 만듭니다:
- 존재하지 않음
- 충분히 고통스럽지 않음
- 너무 적은 사람에게만 영향
- 사람들이 해결에 돈을 내지 않음

문제 검증 프레임워크

문제 검증의 4U

점수화:

• 4/4 U = 해결할 가치가 검증된 문제
• 3/4 U = 유망함, 더 조사 필요
• 2/4 U = 약한 문제, 사업을 지탱하기 어려울 가능성 큼
• 1/4 U = 실제 문제가 아님

문제 인터뷰 스크립트

시작(2분)

"이야기 나눠 주셔서 감사합니다. 저는 사람들이 [문제 영역]을
어떻게 처리하는지 이해하려고 합니다. 정답이나 오답은 없습니다.
경험에서 배우기 위해 왔습니다."

현재 상태(10분)

"역할과 담당하는 일을 설명해 주세요."
"현재 [영역]을 어떻게 처리하는지 처음부터 끝까지 보여 주세요."
"어떤 도구나 프로세스를 사용하나요?"
"매주 이것에 얼마나 많은 시간을 쓰나요?"

문제 탐색(15분)

"[영역]에서 가장 어려운 부분은 무엇인가요?"
"그 일이 마지막으로 발생했을 때를 이야기해 주세요."
"무엇을 했나요? 결과는 어땠나요?"
"이 일이 얼마나 자주 발생하나요?"
"1-10점으로 보면 이 문제가 얼마나 고통스러운가요? 왜 그 점수인가요?"

시도한 솔루션(10분)

"이 문제를 해결하려고 무엇을 시도해 봤나요?"
"그 방법은 얼마나 잘 작동했나요? 아직 무엇이 부족한가요?"
"다른 솔루션을 살펴본 적이 있나요? 어떤 것들이었나요?"
"왜 아직 해결하지 못했나요?"

우선순위화(5분)

"마법 지팡이를 휘두를 수 있다면 무엇이 바뀌면 좋겠나요?"
"이 문제 해결은 우선순위 중 어디에 있나요?"
"이 문제가 절대 해결되지 않으면 어떤 일이 생길까요?"
"이것은 회사가 돈을 내고 해결할 문제인가요?"

검증 신호

강한 문제 신호

+ 이미 해결하려고 시도함(돈/시간 사용)
+ 구체적인 부정적 결과를 설명함
+ 비용을 정량화할 수 있음(시간, 돈, 기회)
+ 여러 사람이 독립적으로 같은 문제를 언급
+ 솔루션이 언제 준비되는지 물어봄
+ 돈을 내거나 설계 파트너가 되겠다고 제안

약한 문제 신호

- "있으면 좋겠네요"
- "쓸 수도 있을 것 같아요"
- 구체적인 예를 들지 못함
- 스스로 해결하려고 시도한 적 없음
- 실제 경험이 아니라 이론적인 문제
- 한 사람만 언급함

위험 신호

! 솔직한 것이 아니라 예의를 차리는 중
! 자신이 아니라 당신을 도와주려 함
! "네, 하지만..." 뒤에 반론이 이어짐
! 현재 우회 방법을 설명하지 못함
! 무료라면 쓰겠지만 돈은 내지 않음

문제 순위 매기기

인터뷰에서 문제 스택 만들기

점수 공식:

문제 점수 = (빈도 x 3) + (심각도 x 2) + (솔루션 격차 x 1)

여기서:
- 빈도 = 인터뷰 대상자 중 몇 명이 언급했는가(1-10)
- 심각도 = 발생했을 때 얼마나 고통스러운가(1-10)
- 솔루션 격차 = 현재 솔루션이 얼마나 부족한가(1-10)

문제 진술문 템플릿

형식 1: 상황-복잡성-질문

상황: [현재 상태]
복잡성: [문제가 되는 이유]
질문: [해결해야 할 것]

예:
상황: 엔지니어링 팀은 여러 환경에서 시크릿을 관리합니다.
복잡성: 시크릿이 .env 파일, Slack 메시지, 위키에 흩어져 있어
        보안 위험과 온보딩 지연을 일으킵니다.
질문: 복사-붙여넣기만큼 쉬우면서도 안전하고 중앙화된 방식으로
      팀이 시크릿을 관리하게 하려면 어떻게 해야 할까요?

형식 2: 사용자-문제-영향

[사용자 세그먼트]는 [문제]로 어려움을 겪고
그 결과 [부정적 영향]이 발생합니다.

예:
스타트업의 DevOps 엔지니어는 시크릿 난립으로 어려움을 겪고
그 결과 보안 취약점이 생기며 신규 입사자 온보딩이 2일 이상 느려집니다.

형식 3: 해야 할 일

[상황]일 때, 나는 [동기]하고 싶다.
그래서 [기대 결과]를 얻고 싶다.

예:
새 개발자를 온보딩할 때, 필요한 모든 시크릿에 대한 접근 권한을 주고 싶다.
그래서 보안을 해치지 않으면서 첫날부터 생산성을 낼 수 있게 하고 싶다.

검증 실험

무엇이든 만들기 전에

랜딩 페이지 테스트

문제와 솔루션을 설명하는 페이지를 만듭니다.
이메일 수집 문구를 추가합니다: "얼리 액세스 받기"
트래픽을 보냅니다(광고, 게시물, 연락)

성공 지표:
- 이메일 가입률 > 20% = 강한 신호
- 10-20% = 유망함
- < 10% = 약한 문제 또는 메시지

스모크 테스트

가격과 함께 솔루션을 설명합니다.
"지금 구매" 또는 "체험 시작" 버튼을 추가합니다.
클릭을 수집합니다(실제 구매는 없음).

성공 지표:
- 클릭률 > 5% = 강한 구매 의도
- 2-5% = 탐색할 가치 있음
- < 2% = 문제 또는 가격 이슈

문제 전환 신호

문제 초점을 전환해야 할 때

- 일관된 고통 지점 없이 인터뷰 5건 이상 진행
- 사용자가 기존 솔루션에 만족
- 문제는 있지만 해결에 돈을 내지 않음
- 시장이 너무 작음(기회 1,000만 달러 미만)
- 문제가 근본 원인이 아니라 증상임

인접 문제 탐색

원래 문제: "보고서가 너무 오래 걸림"
인접 문제:
- 데이터가 부정확함
- 이해관계자가 보고서를 읽지 않음
- 인사이트가 실행 가능하지 않음
- 수동 데이터 수집

때로는 더 큰 문제가 바로 옆에 있습니다.

안티패턴

• 솔루션 우선 사고 — "X를 만들면 어떨까"가 아니라 "어떤 문제가 존재하는가"에서 시작해야 함
• 대리 검증 — 목표 고객 대신 친구/투자자에게 물음
• 확증 편향 — 솔루션에 맞는 문제만 들음
• 단일 인터뷰로 결정 — 한 사람은 시장이 아님
• 기능 요청을 문제로 착각 — "X를 원해요"는 "Y로 어려움을 겪어요"와 다름
• 가정형 검증 — "X를 쓰겠나요?"가 아니라 "지난번에 어땠는지 말해 주세요..."
• 우회 방법 무시 — 우회 방법을 만들었다면 문제를 찾은 것

---

title: 사용자 인터뷰 기법 impact: CRITICAL tags: research, interviews, qualitative, discovery

사용자 인터뷰 기법

영향도: 매우 높음

사용자 인터뷰는 발견의 초석입니다. 좋은 인터뷰는 진실을 드러내고, 나쁜 인터뷰는 편향을 확인해 줄 뿐입니다.

인터뷰 스펙트럼

엄마 테스트

모든 질문은 "엄마 테스트(The Mom Test)"를 통과해야 합니다. 상대가 친절해 보이려고 거짓말할 수 있는 질문인가?

나쁜 질문(엄마가 거짓말할 수 있음)

"X를 하는 앱이 있으면 쓰시겠어요?"
"이 아이디어가 좋은 것 같나요?"
"이것에 얼마를 내시겠어요?"
"이것이 문제를 해결해 줄까요?"

좋은 질문(엄마도 거짓말하기 어려움)

"마지막으로 이 문제가 있었던 때를 이야기해 주세요."
"현재 이것을 어떻게 처리하는지 처음부터 끝까지 보여 주세요."
"이 문제를 해결하려고 무엇을 시도했나요? 어떤 일이 있었나요?"
"오늘 이 문제에 시간/돈을 얼마나 쓰고 있나요?"

질문 프레임워크

넓게 시작해 깊게 들어가기

수준 1: "역할에 대해 이야기해 주세요..."
수준 2: "[영역]에서 가장 큰 어려움은 무엇인가요?"
수준 3: "X를 언급하셨는데, 그것에 대해 더 이야기해 주세요."
수준 4: "이 일이 마지막으로 언제 일어났나요? 처음부터 끝까지 보여 주세요."
수준 5: "그다음에는 무엇을 했나요? 결과는 어땠나요?"

다섯 번의 왜

"우리 보고 체계 때문에 답답합니다."
  → 왜요? "보고서를 만드는 데 너무 오래 걸립니다."
  → 왜요? "서로 다른 세 시스템에서 데이터를 가져와야 합니다."
  → 왜요? "도구들이 연동되지 않습니다."
  → 왜요? "서로 다른 팀을 위해 서로 다른 시기에 구매했습니다."
  → 왜요? "아무도 큰 그림을 생각하지 않았습니다."

근본 원인: 보고 도구 자체가 아니라 통합된 계획의 부재.

타임라인 재구성

"이것이 문제라는 것을 처음 깨달았던 때로 돌아가 보겠습니다..."
"그다음에는 무슨 일이 있었나요?"
"그 후 무엇을 했나요?"
"또 누가 관여했나요?"
"그 시점에 어떤 느낌이었나요?"
"결국 어떤 일이 일어났나요?"

인터뷰 구조

도입(5분)

1. 감사 인사, 기대치 설정
2. 녹화 허가 받기
3. 기밀성 설명
4. 쉬운 워밍업 질문으로 시작

핵심 인터뷰(25-45분)

5. 현재 상태 탐색
6. 문제 심층 탐구(다섯 번의 왜 사용)
7. 과거 행동(미래 약속이 아님)
8. 구체적 예시와 이야기

마무리(5-10분)

9. 요약과 되짚기
10. 또 누구와 이야기하면 좋을지 묻기
11. 감사 인사와 다음 단계 설명

좋은 인터뷰 관행 vs 나쁜 인터뷰 관행

좋은 관행

- 구체적인 과거 행동을 묻습니다
  "마지막으로 그랬던 때를 이야기해 주세요..."

- 상대가 말하게 합니다(상대 80%, 나 20% 목표)
  "음. 그리고 그다음에는요?"

- 에너지가 있는 곳을 따라갑니다
  "X를 언급할 때 답답해 보였어요. 더 이야기해 주세요."

- 구체적으로 만듭니다
  "그걸 어떻게 하는지 보여 주실 수 있나요?"

- 침묵을 받아들입니다(끼어들기 전에 5까지 세기)
  [기다림]

- 이미 쓴 돈에 대해 묻습니다
  "무엇을 시도했나요? 비용은 얼마나 들었나요?"

나쁜 관행

- 미래 행동을 묻습니다(신뢰하기 어려움)
  "쓰시겠어요..." "어떻게 생각하세요..."

- 증인을 유도합니다
  "X가 답답하지 않나요?"

- 인터뷰 중에 판매합니다
  "저희 제품이 이런 걸 한다고 하면 어떠세요..."

- 한 번에 여러 질문을 합니다
  "X는 어떻게 하고 Y도 발생하나요?"

- 모호한 답을 받아들입니다
  "어려워요." → "어떻게 어려운가요? 예를 들어 주세요."

- 말을 끊거나 침묵을 채웁니다
  [아직 생각 중입니다!]

인사이트 포착

인터뷰 중

- 허가를 받고 녹음합니다(항상 백업으로 메모도 함)
- 감정 반응을 기록합니다(답답함, 흥분)
- 정확한 인용문을 포착합니다
- 놀라운 발언에는 "!!" 표시

메모 템플릿

참가자: [이름이 아닌 ID]
날짜:
맥락: [역할, 회사 유형 등]

핵심 인용:
- "[정확한 인용문]" — [주제]에 대해

관찰된 행동:
- 현재 X를 함
- Y를 시도했지만 ... 때문에 작동하지 않음

고통 지점:
- 문제: [설명]
  빈도: [얼마나 자주]
  심각도: [1-10]
  현재 솔루션: [지금 하는 방식]

놀라운 점:
- 예상하지 못함: [관찰]

후속 질문:
- 탐색 필요: [질문]

표본 크기 가이드라인

충분히 했다는 신호

• 같은 주제가 반복됨
• 새로운 문제가 나오지 않음
• 상대가 무엇을 말할지 예측 가능
• 팀이 인사이트에 정렬됨

안티패턴

• 확증 편향 — 가설을 지지하는 말만 들음
• 친절한 사용자 함정 — 당신을 좋아하는 사람과만 이야기
• 유도 질문 — "X가 일어날 때 싫지 않나요?"
• 솔루션 밀어붙이기 — 듣는 대신 판매함
• 대리 인터뷰 — 사용자 대신 영업/지원에 물음
• 성급한 종합 — 인터뷰 2-3건 뒤 결론
• 메모 소홀 — 문서화보다 기억을 신뢰

---

title: 설문 설계 impact: HIGH tags: research, surveys, quantitative, validation

설문 설계

영향도: 높음

설문은 인터뷰가 발견한 것을 정량화합니다. 모르는 것을 탐색하기보다 널리 퍼져 있는 정도와 우선순위를 측정하는 데 사용하세요.

설문을 사용할 때

좋은 사용 사례

- 문제의 확산 정도 검증("이 이슈를 겪는 사람이 얼마나 많은가?")
- 기능 우선순위화("무엇이 가장 중요한가?")
- 만족도 측정(NPS, CSAT)
- 행동으로 사용자 세그먼트화
- 시간에 따른 변화 추적

나쁜 사용 사례

- 새로운 문제 발견(인터뷰 사용)
- "왜"를 이해(설문은 무엇을 알려 주지만 왜는 알려 주지 않음)
- 미래 행동 예측(신뢰하기 어려움)
- 새로운 개념 테스트(프로토타입 테스트 사용)

설문 설계 원칙

1. 목표에서 시작

질문을 쓰기 전에:
- 이 결과가 어떤 결정을 알려 주는가?
- 결과에 따라 무엇을 다르게 할 것인가?
- 데이터를 어떻게 분석할 것인가?

나쁨: "사람들이 우리 제품을 어떻게 생각하는지 보자."
좋음: "3개 기능 중 무엇을 먼저 만들지 결정해야 한다."

2. 짧게 유지

설문 길이의 영향:
- 5분 미만: 완료율 80% 이상
- 5-10분: 완료율 60-70%
- 10-15분: 완료율 40-50%
- 15분 초과: 완료율 30% 미만

규칙: 질문을 줄일 수 있으면 줄이세요.

3. 질문 하나에 개념 하나

나쁨: "우리 제품은 사용하기 쉽고 가격도 적절한가요?"
(쉽지만 비싸다면?)

좋음:
"우리 제품은 얼마나 사용하기 쉬운가요?"
"우리 제품의 가격은 얼마나 적절한가요?"

질문 유형

좋은 질문 작성

좋은 질문

구체적이고 측정 가능:
"지난 30일 동안 [행동]을 몇 번 했나요?"

명확한 선택지:
"없음 / 1-2회 / 3-5회 / 6회 이상"

중립적 표현:
"X를 어떻게 평가하시나요?"

행동 중심:
"마지막으로 [X를 한] 때는 언제인가요?"

나쁜 질문

이중 질문:
"우리 제품은 빠르고 신뢰할 수 있나요?"

유도:
"새 기능을 얼마나 사랑하시나요?"

모호함:
"가끔 문제가 있나요?"

가정형:
"X를 하는 기능이 있으면 쓰시겠어요?"

전문용어 과다:
"ML 기반 NLP 역량에 대해 어떻게 느끼시나요?"

척도 설계

리커트 척도(동의)

5점: 전혀 동의하지 않음 → 매우 동의함
7점: 동일하되 "다소" 선택지 포함

권장 관행:
- 중립 지점을 두려면 홀수 사용
- 방향을 강제하려면 짝수 사용
- 설문 전체에서 일관성 유지

평정 척도(만족도/품질)

1-5: 단순하고 익숙하며 대부분의 경우 충분
1-7: 더 세분화가 필요할 때
1-10: 익숙하지만 해석이 일관되지 않음

권장 관행:
- 항상 양 끝에 라벨을 붙임
- 모든 점에 라벨을 붙일지 고려
- 보통 1-5면 충분

NPS(순추천지수)

"X를 동료에게 추천할 가능성이 얼마나 되나요?"
0-10 척도

점수화:
- 추천자: 9-10
- 중립자: 7-8
- 비추천자: 0-6
- NPS = 추천자 비율 - 비추천자 비율

항상 이어서 묻기: "그 점수를 준 가장 주된 이유는 무엇인가요?"

설문 구조

최적 흐름

1. 선별 질문(부적합 응답자 필터링)
2. 쉽고 참여를 유도하는 질문(흐름 만들기)
3. 핵심 질문(주요 데이터 확보)
4. 민감한/인구통계 질문(끝부분에 배치)
5. 주관식 질문(선택, 깊이를 위해)

구조 예시

1. 선별: "[제품 카테고리]를 사용하나요?" (예/아니요)
2. 워밍업: "주요 역할은 무엇인가요?" (객관식)
3. 핵심: "[X]에 얼마나 만족하나요?" (척도)
4. 핵심: "이 기능들을 중요도순으로 정렬하세요" (순위)
5. 인구통계: "회사 규모는?" (객관식)
6. 주관식: "현재 솔루션에서 무엇이 부족한가요?" (텍스트)

표본 크기 계산기

빠른 규칙:

• 작은 결정: 응답 50-100개
• 중간 결정: 응답 100-300개
• 큰 결정: 응답 300개 이상

설문 배포

응답률 높이기

- 짧게 유지(5분 미만)
- 왜 하는지와 누가 혜택을 받는지 설명
- 초대 문구 개인화
- 보상 제공(신중하게)
- 리마인더 발송(최대 2-3회)
- 모바일 친화적 설계

분석 프레임워크

정량 분석

1. 응답률과 완료율
2. 기술 통계(평균, 중앙값, 분포)
3. 세그먼트 비교(역할, 회사 규모 등)
4. 교차 분석(X는 Y와 어떤 관계인가?)
5. 통계적 유의성(큰 결정의 경우)

주관식 분석

1. 모든 응답 읽기
2. 주제 코딩(범주 태그 지정)
3. 주제 빈도 집계
4. 대표 인용문 추출
5. 놀라운 점 찾기

설문 템플릿: 기능 우선순위화

1. "주요 역할은 무엇인가요?"
   [ ] 엔지니어링 [ ] 제품 [ ] 디자인 [ ] 기타

2. "[사용 사례]를 얼마나 자주 사용하나요?"
   [ ] 매일 [ ] 매주 [ ] 매월 [ ] 드물게 [ ] 전혀 없음

3. "각 역량은 당신에게 얼마나 중요한가요?"
   [각 기능별 1-5 척도]

4. "각 항목에 대한 현재 솔루션에 얼마나 만족하나요?"
   [각 기능별 1-5 척도]

5. "한 가지만 개선할 수 있다면 무엇을 개선하겠나요?"
   [주관식 텍스트]

6. "그 밖에 알아야 할 것이 있나요?"
   [주관식 텍스트]

안티패턴

• 설문 우선 리서치 — 인터뷰 전에 설문부터 함(잘못된 질문을 하게 됨)
• 질문 과다 — 질문 하나마다 완료율 비용이 듦
• 유도 척도 — "나쁨, 보통, 좋음, 매우 좋음, 훌륭함"(긍정 쪽으로 편향)
• 필수 주관식 — 사람들은 진행하려고 아무 말이나 씀
• 설문 피로 — 같은 사용자에게 너무 자주 설문
• 완료율 무시 — 완료율 20%는 편향 80%를 의미
• 과도한 설계 — 단순한 설문이 복잡한 설문보다 낫습니다

---

title: 프로토타입 테스트 impact: HIGH tags: testing, prototypes, validation, concepts

프로토타입 테스트

영향도: 높음

만들기 전에 개념을 테스트하세요. 하루의 프로토타입 테스트는 잘못된 것을 만드는 몇 달을 절약합니다.

프로토타입 충실도 스펙트럼

프로토타입 충실도 선택

충실도를 질문에 맞추기

질문: "이것이 해결할 올바른 문제인가?"
→ 종이 스케치, 대화
→ 프로토타입이 전혀 필요하지 않음

질문: "이 업무 흐름이 말이 되는가?"
→ 낮은 충실도의 와이어프레임, 종이 프로토타입
→ 다듬음이 아니라 흐름을 테스트

질문: "사용자가 이 작업을 완료할 수 있는가?"
→ 클릭 가능한 프로토타입
→ 이동할 만큼 충분하지만 주의를 빼앗지 않게

질문: "이것이 원하고 가치 있는가?"
→ 고충실도 프로토타입
→ 솔직한 반응을 얻으려면 실제처럼 보여야 함

질문: "기술적으로 가능한가?"
→ 기능형 프로토타입 / 스파이크
→ 실제 코드, 제한된 범위

종이 프로토타입 테스트

사용할 때

• 매우 초기 탐색
• 넓은 개념 테스트
• 빠른 반복 필요
• 리소스 제약

진행 방법

준비:
1. 핵심 화면을 종이/카드에 스케치
2. "시작 화면" 준비
3. 새 화면용 빈 카드 준비

진행:
1. 설명: "아직 만들어지지 않은 초기 아이디어입니다"
2. 시작 화면 제시
3. 질문: "[작업을 달성]하려면 무엇을 하시겠어요?"
4. 사용자가 "클릭"하면 다음 화면으로 교체
5. 혼란, 망설임, 예상 밖 경로 기록

회고:
- 무엇이 이해됐나요?
- 무엇이 혼란스러웠나요?
- 무엇이 빠졌나요?

개념 테스트

실행 전에 아이디어 테스트

개념 테스트 스크립트

소개:
"초기 개념을 보여 드리겠습니다. 아직 만들어진 것은 아니고,
가치가 있을지 배우려는 단계입니다."

첫인상(설명 전):
"이것이 무엇이라고 생각하시나요?"
"누구를 위한 것 같나요?"
"무엇을 할 것이라고 기대하나요?"

살펴보기:
[개념 보여 주기]
"무엇이 눈에 띄나요?"
"어떤 질문이 생기나요?"

가치 평가:
"1-10점으로 보면 이것이 당신에게 얼마나 가치 있을까요?"
"무엇이 있으면 더 가치 있을까요?"
"이것이 없다면 대신 무엇을 쓰겠나요?"

구매 의도:
"이것에 돈을 내겠나요?"
"얼마 정도를 예상하나요?"
"무엇이 사용을 막을까요?"

클릭 가능한 프로토타입 테스트

프로토타입 만들기

도구: Figma, Sketch, InVision, Framer

포함:
- 정상 흐름(주요 흐름)
- 핵심 의사결정 지점
- 오류 상태(견고성을 테스트하는 경우)
- 현실적인 콘텐츠("의미 없는 더미 텍스트"가 아님)

제외:
- 모든 예외 사례
- 애니메이션(애니메이션을 테스트하는 경우 제외)
- 완전한 디자인 시스템

테스트 진행

작업 기반 테스트:

1. 맥락 설정(하지만 지시하지 않음)
   "[시나리오]에 있다고 상상해 보세요. [목표]를 원합니다."

2. 소리 내어 생각하도록 요청
   "진행하면서 무슨 생각을 하는지 말해 주세요."

3. 도와주지 않고 관찰
   기록: 망설임, 잘못된 경로, 질문

4. 후속 질문
   "거기서 어떤 일이 일어날 것으로 기대했나요?"
   "다음에는 무엇을 하겠나요?"

5. 회고
   "이것을 동료에게 어떻게 설명하겠나요?"
   "무엇이 혼란스러웠나요?"
   "무엇이 빠졌나요?"

프로토타입 테스트 지표

테스트 중 측정

테스트 후 측정

A/B 프로토타입 테스트

여러 개념 테스트

접근법 1: 참가자 내 비교
- 각 참가자에게 모든 개념을 보여 줌
- 순서를 무작위화
- 직접 비교
- 적합: 선호 이해

접근법 2: 참가자 간 비교
- 참가자 한 명에게 개념 하나만 보여 줌
- 서로 다른 사람이 서로 다른 버전을 봄
- 집단 간 비교
- 적합: 편향 없는 반응

비교 프레임워크

각 개념을 평가:
- 명확성(이해하는가?)
- 가치(원하는가?)
- 사용성(쓸 수 있는가?)
- 선호(무엇을 더 선호하는가?)

그다음 질문:
- "무엇을 선택하겠나요? 왜인가요?"
- "[덜 선호한 것]이 더 좋아지려면 무엇이 필요할까요?"

흔한 프로토타입 테스트 실수

실수 1: 너무 일찍 테스트

문제: 개념이 덜 익어 피드백이 노이즈가 됨
수정: 테스트 전에 핵심 가정을 파악

실수 2: 너무 늦게 테스트

문제: 이미 확정되어 테스트가 보여주기식이 됨
수정: 아직 방향을 바꿀 수 있을 때 테스트

실수 3: 잘못된 사람과 테스트

문제: 친구/동료는 사용자가 아님
수정: 실제 목표 사용자를 모집

실수 4: 너무 많이 설명

문제: "작동 방식은 이렇습니다..."가 현실적인 맥락을 제거
수정: 맥락만 설정하고 관찰

실수 5: 유도 질문

문제: "이거 쉽다고 생각하지 않나요?"
수정: "난이도를 어떻게 설명하시겠어요?"

결과 해석

강한 긍정 신호

+ 도움 없이 작업 완료
+ "언제 쓸 수 있나요?"
+ 돈을 내거나 설계 파트너가 되겠다고 제안
+ 현재 솔루션보다 좋게 비교
+ 가치/사용 가능성 척도에서 8점 이상

약한/부정적 신호

- 진행하려면 설명이 필요함
- "흥미롭네요"(예의상 보이는 무관심)
- "쓸 수도 있을 것 같아요"(가정형)
- 경쟁사와 비교해 불리함
- 가치/사용 가능성 척도에서 6점 미만

결과로 무엇을 할 것인가

빠른 반복 주기

테스트-학습-반복 루프

1일차: 프로토타입 만들기
2일차: 사용자 3명과 테스트
3일차: 종합하고 상위 이슈 3개 식별
4일차: 프로토타입 업데이트
5일차: 사용자 3명 추가 테스트
...수익 체감이 올 때까지 반복

반복 의사결정 트리

사용자가 작업을 완료했는가?
├── 예 → 쉽게 했는가?
│       ├── 예 → 가치가 명확한가?
│       │       ├── 예 → 출시
│       │       └── 아니요 → 메시지 수정
│       └── 아니요 → 사용성 이슈 수정
└── 아니요 → 개념은 맞는가?
          ├── 예 → 심각한 막힘 지점 수정
          └── 아니요 → 문제/개념 재검토

안티패턴

• 너무 이른 픽셀 완성도 — 다듬음이 아니라 개념을 테스트해야 할 때 고충실도 제작
• 진공 상태 테스트 — 작업 맥락 없이 "어떻게 생각하세요?"만 묻기
• 너무 많이 도와주기 — 어려워할 때 설명함(현실에서는 당신이 옆에 없음)
• 표본 1명 — 단일 테스트로 큰 결정
• 부정적 신호 무시 — "그냥 이해를 못 한 거야"(어쩌면 불명확한 것)
• 기능 검증 연극 — 배우기 위해서가 아니라 확인하기 위해 테스트
• 프로토타입-제품 간 격차 — 프로토타입은 잘 테스트됐지만 실제 제품이 맞지 않음

---

title: 사용성 테스트 impact: HIGH tags: testing, usability, ux, validation

사용성 테스트

영향도: 높음

사용성 테스트는 실제 사용자가 제품으로 실제 작업을 해낼 수 있는지 보여줍니다. 고객에게 비용으로 돌아가기 전에 마찰을 찾는 가장 빠른 방법입니다.

사용성 테스트 기본

사용성 테스트가 측정하는 것

사용성 테스트를 실행할 때

사용성 테스트에 적합

- 기존 제품 흐름 평가
- 재설계된 기능 테스트
- 설계 대안 비교
- 온보딩 마찰 찾기
- 정보 구조 검증
- 특정 사용자 세그먼트와 테스트

사용성 테스트에 부적합

- 문제가 해결할 가치가 있는지 검증(문제 인터뷰 사용)
- 시장 도입 예측(개념 테스트 사용)
- 사용자 니즈 이해(발견 인터뷰 사용)
- 실제 사용량 측정(분석 사용)

테스트 유형

연구 계획

테스트 범위 정의

1. 무엇을 테스트하는가?
   [구체적 기능/흐름]

2. 어떤 질문에 답해야 하는가?
   - 사용자가 X를 찾을 수 있는가?
   - 사용자가 Y를 이해하는가?
   - 사용자는 어디에서 막히는가?

3. 누구와 테스트하는가?
   [목표 사용자 기준]

4. 성공 기준은 무엇인가?
   - X%가 작업을 성공적으로 완료
   - 평균 시간 < Y분
   - SUS 점수 > Z

표본 크기 가이드라인

작업 작성

좋은 작업의 특징

- 시나리오 기반(현실적 맥락)
- 목표 중심(어떻게가 아니라 무엇)
- 힌트 없음(답을 알려 주지 않음)
- 측정할 만큼 구체적
- 실제 사용에 중요

좋은 작업 vs 나쁜 작업

작업 템플릿

시나리오:
[작업을 현실적으로 만드는 맥락]

작업:
[지시 없이 명확한 목표]

성공 기준:
[성공했는지 알 수 있는 방법]

예:
시나리오: 방금 서비스에 가입했고 팀원이 서비스를 쓰기 시작할 수 있도록
          팀원을 추가하고 싶습니다.

작업: Alex Smith라는 동료를 [email protected] 이메일로 팀에 추가하세요.

성공 기준: 새 구성원이 보이는 팀 페이지에 사용자가 도달합니다.

세션 진행

세션 구조(60분)

0:00 - 환영 및 설정(5분)
       - 감사 인사, 목적 설명
       - 녹화 동의 받기
       - 생각 말하기 프로토콜 설명

0:05 - 배경 질문(5분)
       - 관련 경험
       - 현재 도구/프로세스
       - 제품 친숙도

0:10 - 작업(40분)
       - 작업 3-5개
       - 전 과정에서 생각 말하기
       - 각 작업 후 질문

0:50 - 마무리(10분)
       - 전체 인상
       - SUS 또는 만족도 척도
       - 참가자의 질문

진행자가 해야 할 것과 하지 말아야 할 것

유용한 탐색 질문

멈췄을 때:
- "무슨 생각을 하고 있나요?"
- "어떤 일이 일어날 것으로 기대하나요?"

무언가를 클릭했을 때:
- "무엇 때문에 그것을 선택했나요?"
- "무엇을 보게 될 것으로 기대하나요?"

막힌 것처럼 보일 때:
- "실제 상황이라면 무엇을 하겠나요?"
- "시도해 보고 싶은 것이 있나요?"

작업을 완료했을 때:
- "어땠나요?"
- "그게 제대로 된 것이라고 얼마나 확신하나요?"

생각 말하기 프로토콜

동시 생각 말하기

사용자가 작업하면서 말로 설명합니다.
+ 실시간 인사이트
- 행동에 영향을 줄 수 있음
- 일부 사용자는 어려워함

회고형 생각 말하기

사용자가 자신의 녹화를 보며 설명합니다.
+ 테스트 중 행동이 더 자연스러움
- 느리고 다시 보기가 필요함
- 일부 세부가 잊힐 수 있음

생각 말하기 안내

소개:
"작업을 진행하면서 무엇을 보고 있는지, 무엇을 하려는지,
무엇이 일어날 것으로 기대하는지, 어떤 반응이 있는지
소리 내어 말해 주세요.

혼자 이 일을 하고 있지만 스스로에게 말하고 있다고 생각해 주세요.
정답이나 오답은 없습니다. 우리는 당신이 아니라 제품을 테스트합니다."

리마인더:
"지금 무슨 생각을 하고 있나요?"
"계속 말씀해 주세요..."

결과 측정

정량 지표

시스템 사용성 척도(SUS)

질문 10개, 1-5 척도(전혀 동의하지 않음 → 매우 동의함)

1. 이 제품을 자주 사용하고 싶습니다
2. 이 제품은 불필요하게 복잡합니다
3. 이 제품은 사용하기 쉽습니다
4. 이 제품을 사용하려면 지원이 필요할 것입니다
5. 기능들이 잘 통합되어 있습니다
6. 일관성이 너무 부족합니다
7. 대부분의 사람이 빠르게 배울 것입니다
8. 사용하기 매우 번거롭습니다
9. 이 제품을 사용할 때 자신감이 있었습니다
10. 시작하기 전에 많은 것을 배워야 했습니다

점수화:
- 홀수 질문: 점수 - 1
- 짝수 질문: 5 - 점수
- 합계 x 2.5 = SUS 점수(0-100)

해석:
- >80: 훌륭함
- 68-80: 좋음
- 50-67: 개선 필요
- <50: 나쁨

결과 분석

심각도 평정 척도

결과 템플릿

결과: [간단한 설명]

심각도: [1-4]

근거:
- 참가자 [Y]명 중 [X]명이 경험
- 작업: [어떤 작업]
- 행동: [무슨 일이 있었나]
- 인용문: "[그들이 한 말]"

권고안:
[구체적 수정 또는 탐색 방향]

이슈 우선순위 매트릭스

                    높은 빈도
                          │
                          │
        치명적 수정       │    최우선
        (많은 사람,       │    (많은 사람,
         우회 가능)       │     완료 불가)
                          │
    ──────────────────────┼────────────────────
                          │
        낮은 우선순위     │    쉬우면 수정
        (영향받는 사람 적음, │  (사람은 적지만,
         영향 작음)       │     영향 큼)
                          │
                    낮은 빈도

원격 비진행 테스트

도구: UserTesting, Maze, Lookback, UsabilityHub

사용할 때:

• 빠르게 더 많은 참가자가 필요
• 지리적 다양성
• 진행 예산 제한
• 정량 지표 우선

설정 체크리스트:

[ ] 명확한 작업 지시
[ ] 작동하는 프로토타입 링크
[ ] 선별 질문
[ ] 녹화 동의
[ ] 작업 후 질문
[ ] 완료 기준

주의할 점:

• 진행자가 있는 테스트보다 참여도가 낮음
• 후속 질문을 할 수 없음
• 녹화 관련 기술 문제
• 참가자가 서두를 수 있음

결과 보고

사용성 보고서 구조

1. 경영진 요약
   - 핵심 결과(상위 3-5개)
   - 전체 사용성 점수
   - 권장 우선순위

2. 방법론
   - 누구와 테스트했는가
   - 무엇을 테스트했는가
   - 어떻게 테스트했는가

3. 작업별 결과
   - 성공률
   - 작업 시간
   - 발생한 이슈
   - 심각도 평정

4. 주요 이슈
   - 이슈 설명
   - 근거
   - 심각도
   - 권고안

5. 긍정적 결과
   - 잘 작동한 것
   - 사용자 인용문

6. 권고안
   - 우선순위가 매겨진 조치 항목
   - 빠른 성과 vs 장기 과제

안티패턴

• 너무 늦은 테스트 — 제품이 이미 만들어져 바꿀 수 없음
• 동료와 테스트 — 동료는 사용자가 아님
• 너무 많은 작업 — 참가자 피로, 성급한 답변
• 참가자 유도 — "여기를 클릭하겠죠?"
• 너무 많이 도와주기 — 실제 사용자는 당신이 옆에 없음
• 긍정 신호 무시 — 문제에만 집중
• 지표 과다 — 모든 것을 측정하고 아무것도 배우지 못함
• 한 번만 테스트 — 사용성은 한 번이 아니라 반복입니다