제(23일 차)가 방법론과 데스크 리서치였다면, 오늘은 드디어 사용자한테 직접 물어보기 위한 준비를 하는 날이었다. 오전엔 어제 과제 리뷰를 받았고, 오후엔 누구에게, 무엇을, 어떻게 물을지 그 준비 과정을 배웠다. 내일은 실제로 인터뷰를 진행한다고 해서, 오늘은 온통 그 채비를 하는 시간이었다.
지난 과제에서 챙겨야 할 것들
오전 피드백에서 나온 것들 중, 앞으로 계속 참고할 만한 점들을 상황별로 정리해뒀다.
| 비즈니스 모델을 쓸 때 | 가치 제안은 '기능'이 아니라 사용자가 얻는 '가치'로. 핵심 파트너십은 외부 전략 파트너(내부 팀은 활동·비용 쪽). 출처 명시, 문서 표기 통일 |
| 문제를 파고들 때 | 표면적 불편에서 멈추지 말고 '왜'를 캐기. 내 불편에 몇 명이 공감하는지 VOC로 비율 확인. 제작자 관점이 아니라 사용자 관점 |
| 화면을 볼 때 | '가디건을 사고 싶다' 같은 상황을 정하고 몰입해서 플로우를 따라가기 (그냥 하나씩 눌러보는 것보다 낫다) |
| 방향을 좁힐 때 | 페인 포인트를 몇 갈래로 묶고, 우선순위 매트릭스(임팩트 × 노력)로 ROI가 높은 것을 선택 |
| AI를 쓸 때 | '단순한 ~보다', '~를 통해' 같은 AI·번역투를 피하고, 중요한 키워드를 앞에, 간결하게 |
특히 '내 불편에 몇 명이 공감하는지 확인하라'는 말이 계속 남았다. 내가 독특한 사용성을 원하는 걸 수도 있으니, 나의 불편을 프로젝트로 가져가려면 그게 다수의 문제인지부터 확인해야 한다는 것.
책상을 떠나 사용자에게 — 필드 리서치
데스크 리서치가 책상 위 자료를 모으는 일이었다면, 필드 리서치는 실제 사용자에게 가서 직접 묻고 관찰하는 일이다. 데스크 리서치가 전반적인 맥락과 흐름을 봤다면, 필드 리서치는 타깃 사용자가 실제로 어떻게 느끼고 행동하는지를 확인한다. 어제까지 데스크 리서치에서 '의심스러웠던 지점'을 진짜 경험으로 검증하는 단계인 셈이다.
한 가지 주의가 있었다. 이미 아는 뻔한 사실을 다시 묻지 말 것. "사람들은 빠른 배송을 좋아할까" 같은 질문은 결과도 뻔하다. 필드 리서치는 데스크 리서치로는 알 수 없었지만 궁금했던 것을 확인하기 위해 하는 것이다.
필드 리서치의 두 축은 설문조사와 심층 인터뷰인데, 역할이 다르다.
| 얻는 것 | 정량 (숫자·규모) | 정성 (이유·맥락) |
| 표본 | 크고 다양하게 (수백~수천) | 소수 (몇~수십 명) |
| 강점 | 얼마나 많은 사람이 겪는지 | 왜 그렇게 느끼는지 |
| 속도·비용 | 빠르고 저렴 | 느리고 비쌈 |
표본은 무조건 많다고 좋은 게 아니라, 더 이상 새로운 게 안 나오는 데이터 포화점까지면 된다. 정성 리서치는 5명만 해도 사용성 문제의 약 85%가 발견된다는 연구가 있어서 보통 5~8명(최대 15명)이면 충분하고, 정량 설문은 오차범위 ±10%면 최소 100명, ±5%면 400명 이상이 필요하다. 결국 중요한 건 많은 수가 아니라, 문제와 가장 밀접한 고관여 사용자를 만나는 것이었다.
좋은 질문보다 좋은 사람 — 대상 선정
오늘 가장 크게 남은 말은 이거였다. 좋은 질문을 만드는 것만큼 물어볼 사람을 잘 고르는 게 중요하다는 것. 아무한테나 묻는 의견 조사가 아니라, 알고 싶은 문제와 가장 가까운 사람을 만나야 한다. 사용자를 대신해 말해줄 수 있는 사람이 아니라, 실제 사용자를 만나라는 것이다.
참여자를 고르는 세 가지 원칙이 있었다. 리서치 목적과 참여자 특성이 일치할 것, 추측이나 의견이 아니라 직접 경험한 사람일 것, 그리고 편향을 줄이기 위해 만족·불만족 고객을 두루 포함할 것. 강사님은 결혼식으로 비유했는데, 왜 안 왔는지 궁금하면 안 온 사람을 만나야지 온 사람한테 물으면 "저는 갔는데요"밖에 안 나온다는 것. 목적이 바뀌면 만나야 할 대상도 바뀐다.
여기서 포함 기준(인구통계·경험·행동·기술 수준)과 제외 기준(이해관계 충돌·리서치 과다 참여·개인적 제약)을 정한다. 포함 기준과 제외 기준 — 이 말은 임상연구에서 대상자를 모을 때 그대로 쓰던 말이라 반가웠다. 연구에 맞는 사람을 고르는 일이 결과의 신뢰도를 좌우한다는 것도 똑같았다.
대상은 사용자(헤비·라이트·고관여·얼리어답터)와 비사용자(이탈자·경쟁사 사용자·잠재 사용자)로 나뉘는데, 성공자와 이탈자처럼 비교 가능한 그룹을 같이 보면 어디서 경험이 갈라지는지 더 잘 보인다.
무엇을 어떻게 물을까 — 목적, 투두리스트, 그리고 인터뷰 흐름
인터뷰 준비는 무작정 질문부터 쓰는 게 아니었다. 먼저 조사 배경(왜 지금 이 조사가 필요한지)과 조사 목적(무엇을 알아내고 싶은지)을 정하고, 그다음 투두리스트를 만든다. 투두리스트는 이번 리서치에서 반드시 파악해야 할 핵심 정보·행동·가설의 목록이다. 질문이 문장이라면, 투두리스트는 그 질문으로 알아내야 하는 핵심 정보 — 한 단계 위에 있는 셈이다. 조사 배경 → 목적 → 투두리스트 → 대상 조건이 하나의 맥락으로 이어져야 한다.
실제 인터뷰는 40~60분 정도로, 흐름은 이렇게 간다. 처음 5분은 가벼운 잡담으로 긴장을 푸는 라포 형성, 그다음 "주로 언제 사용하세요?"처럼 넓게 여는 열린 질문, 이어서 구체적인 행동·니즈로 좁히는 닫힌 질문, 마지막으로 대화 중 생긴 궁금증을 파고드는 추가 질문. 다만 순서대로만 가는 게 아니라, 질문 리스트를 준비해두고 열린·닫힌·추가 질문을 왔다 갔다 하는 반구조화 인터뷰로 진행한다고 했다.
추가 질문에서 쓰는 게 5 Whys다. 근본 원인까지 "왜"를 반복하는 것. 화장품 필터 창을 닫은 사용자에게 물어보면, 필터가 너무 많아서 → 시카·레티놀 같은 어려운 용어가 섞여 있어서 → 내 피부에 맞는 성분을 몰라서 → 실패하고 싶지 않아서 → 화장품은 오래 써야 하는데 정보 없이 고르는 게 불안해서, 로 내려간다. 진짜 문제는 필터 개수가 아니라 '낯선 용어로 인한 선택 실패 불안'이었던 것. 다만 "왜"를 그대로 반복하면 압박적이라 표현은 순화해야 한다.
사람을 거르는 짧은 설문 — 스크리너
인터뷰 참여자를 모집하기 전에 쓰는 짧은 설문이 스크리너다. 목적에 맞는 사람인지 확인하고 부적절한 사람을 미리 걸러낸다. 사람을 거르는 도구이면서, 동시에 사용자를 분류하는 도구이기도 하다.
스크리너에는 네 가지 원칙이 있었다. 짧게(8~15문항, 2~5분)라는 효율성, 부적격 답변이면 즉시 종료하는 로직 분기, 구체적인 수치로 묻는 명확성, 그리고 답을 유도하지 않는 충실성. 문항은 중립적이고 구체적이어야 하는데, 나쁜 질문을 좋은 질문으로 바꿔보는 연습이 특히 도움이 됐다.
| 운동을 좋아하시나요? | 지난 2주간 운동을 몇 번 하셨나요? |
| 최신 기술에 관심이 많으신가요? | 최근 1년 안에 설치한 앱은 몇 개인가요? |
| 저희 서비스에 만족하시나요? | 지난달 가장 불편했던 점은 무엇인가요? |
추상적인 질문은 수치로, 주관적인 질문은 객관적인 행동으로, 유도성 질문은 중립적인 표현으로 바꾸는 것이 핵심이었다. 스크리너 구조는 도입·동의 → 자격 확인 → 행동·경험 → 제외 기준 → 인구통계 → 일정·연락처 → 마무리의 순서로 짜고, 시작과 마무리 멘트(목적·소요 시간·리워드·감사)도 생각보다 중요하다고 했다.
정리하며
오늘은 대화를 나누기 전의 준비에 대한 날이었다. 좋은 인터뷰는 영리한 질문보다 물어볼 사람을 잘 고르는 데서 갈린다는 것, 그리고 질문은 거꾸로 준비한다는 것 — 조사 배경과 목적을 먼저 세우고, 투두리스트로 무엇을 알아낼지 정한 다음에야 질문을 쓴다는 것.
물어볼 대상을 정하고 기준으로 걸러내는 일은, 연구에 맞는 사람을 신중히 고르던 감각과 닮아 있어서 낯설지 않았다. 내일은 드디어 실제 인터뷰다. 네 번의 세션 중 두 번은 진행자로, 두 번은 인터뷰이로 참여한다고 하니, 오늘 준비한 걸로 직접 물어보고 또 답해보게 된다.
'오즈코딩스쿨 디자인캠프' 카테고리의 다른 글
| 오조코딩스쿨 디자인 캠프 - 어피니티 다이어그램으로 정리하자 (day 26) (0) | 2026.07.07 |
|---|---|
| 오즈코딩스쿨 - 사용자를 인터뷰 해보자! (day25) (1) | 2026.07.07 |
| 오즈코딩스쿨 디자인 캠프 - 답을 정하지 않고 단서부터 모으기 — UX 리서치 방법론과 도구들 (day23) (0) | 2026.07.01 |
| 오즈코딩스쿨 디자인 캠프 - '예쁘니까요'로는 설득할 수 없다 — UX 리서치를 시작하며 (day22) (1) | 2026.06.29 |
| 오즈코딩스쿨 디자인 캠프 - 피그마 마지막 수업 — 도구를 정리하고, AI가 그리는 화면을 보다 (day21) (0) | 2026.06.26 |