사용자 리서치 분석 프레임워크: 인터뷰 메모에서 핵심 주제까지

김희준

2026년 10월 18일업데이트

사용자 리서치 분석 프레임워크는 인터뷰 메모에서 공통 주제를 찾고 다음 의사결정으로 연결하는 틀입니다. 무엇을 관찰했고 어떤 과정을 거쳐 패턴을 찾았는지 남겨 두면, 결론을 다시 검토할 때도 근거를 확인할 수 있습니다. 아직 조사 계획을 세우지 않았다면 사용자 리서치 계획 템플릿(영문)부터 참고하세요.

인터뷰 메모를 코드, 주제, 제품 의사결정으로 정리하는 흐름 — 인터뷰 메모를 묶어 공통 주제를 찾고, 다음에 검증할 과제를 정합니다.

1. 분석으로 답할 질문부터 정한다

메모에 코드를 붙이기 전에 분석을 통해 무엇을 결정할지 한 문장으로 적습니다. 예를 들어 “온보딩의 어떤 문제를 다음에 검증할 것인가?”입니다. 대상 사용자, 제품 범위, 의사결정의 대상 기간도 명시합니다. 흥미롭지만 실제 결정에는 도움이 되지 않는 관찰로 분석 범위가 넓어지는 것을 막을 수 있습니다.

먼저 정리할 네 가지

질문: 아직 결정하지 못한 것은 무엇인가?
근거: 어떤 인터뷰, 작업, 자료를 분석할 것인가?
제약: 이번에는 바꿀 수 없는 조건이 무엇인가?
결과물: 제품, 디자인, 지원 담당자에게 무엇을 전달할 것인가?

2. 메모 형식을 통일한다

각 메모를 짧은 관찰 내용, 참여자의 상황, 출처로 나눕니다. 참여자의 말과 조사자의 해석은 구분해야 합니다. “변화가 보이지 않아서 두 번 클릭했어요”는 참여자의 발언입니다. 반면 “인터페이스의 피드백이 부족하다”는 그 발언을 바탕으로 세운, 검증이 필요한 가설입니다.

의미 있는 관찰 하나를 카드 한 장에 적습니다. 인터뷰 번호나 작업 이름을 출처로 붙이고, 공유 보드에는 개인을 식별할 수 있는 정보를 올리지 않습니다.

3. 화제보다 행동에 초점을 맞춰 코딩한다

코드는 메모의 내용을 짧게 나타내는 라벨입니다. “상태를 찾음”, “같은 단계를 반복함”, “확인을 요청함”, “오류 후 이탈함”처럼 행동을 나타내는 코드부터 만듭니다. “대시보드”, “알림” 같은 분류명은 자료를 정리하기에는 좋지만 무엇을 바꿔야 하는지는 설명하지 못합니다. 근거가 있다면 한 메모에 여러 코드를 붙여도 됩니다.

첫 분류가 끝나면 중복 코드를 합치고 각 코드에 한 줄 정의를 남깁니다. 다른 조사자도 같은 기준으로 적용할 수 있도록 하는 것이 목적입니다.

4. 관찰을 묶어 핵심 주제를 정리한다

비슷한 행동이나 요구를 설명하는 메모를 모읍니다. 주제는 상황과 그 결과가 드러나는 문장으로 씁니다. 예를 들어 “초대가 전송됐는지 알 수 없어 같은 작업을 반복하거나 동료에게 확인한다”입니다. “불편한 UX”라는 표현만으로는 근거나 개선 방향을 알기 어렵습니다.

주제를 뒷받침하는 메모뿐 아니라 그와 맞지 않는 메모, 아직 확인하지 못한 점도 기록합니다. 현재 근거로 어디까지 설명할 수 있는지 구분하세요.

5. 주제를 개선을 위한 질문으로 바꾼다

각 주제를 “단계를 추가하지 않고 초대 상태를 어떻게 보여 줄 수 있을까?”처럼 개선 방향을 탐색하는 질문으로 바꿉니다. 해결책을 먼저 확정하지 않아야 나중에 여러 대안을 비교할 수 있습니다. 다음 검증 내용과 담당자도 함께 정합니다.

다음은 정리 방식의 예시입니다.

주제	근거	개선을 위한 질문	다음 검증
초대 상태가 불명확함	두 작업에서 나온 메모 3건	초대 상태를 어떻게 보여 줄까?	상태 표시 프로토타입 테스트
다음 행동을 알기 어려움	데이터가 없는 초기 화면에서 나온 메모 2건	첫 단계를 어떻게 안내할까?	안내 문구 두 가지 비교

6. 결정하기 전에 불확실한 점을 검토한다

우선순위를 정하기 전에 어떤 정보가 추가되면 해석이 달라질 수 있는지 생각합니다. 조사 설계가 허용하는 범위에서 참여자의 상황, 작업, 사용자 집단별 차이를 비교하세요. 소규모 표본이나 특정 조건에 따라 선정한 참여자의 결과를 전체 사용자에게 나타나는 비율로 해석해서는 안 됩니다. 해결하지 못한 질문과 답을 얻는 데 필요한 근거를 남깁니다.