지난 편에서 사용 맥락의 네 가지 구성 요소와 맥락이 의사결정에 미치는 영향을 살펴봤어요. 이번 편에서는 사용 맥락을 실제로 파악하는 방법인 맥락 조사(Contextual Inquiry)의 정의, 핵심 원칙, 그리고 관찰과 해석의 차이를 알아볼게요.
1. 맥락 조사: 실제 사용자 행동을 이해하는 법
대부분의 프로덕트 리서치는 대화를 통해 이뤄져요.
맥락 조사는 현실 위에 만들어져 있죠. 사용자에게 기억하거나 설명하거나 상상해보라고 요청하는 대신, 리서처가 사용자의 실제 작업 맥락 안에 직접 들어갈 수 있도록 해요.
1) 맥락 조사란 무엇인가
맥락 조사(Contextual Inquiry)는 이런 리서치 접근법이에요.
- 사용자를 실제 환경에서 관찰한다
- 실제 과업을 수행하는 것을 지켜본다
- 사후가 아니라 그 순간에 질문한다
맥락 조사의 목표는 아이디어를 검증하는 게 아니라, 일이 실제로 어떻게 일어나는지 이해하는 거예요.
전통적인 인터뷰나 설문조사는 기억과 표현 능력에 의존하지만, 맥락 조사는 사용자의 행동, 환경, 방해 요소, 또는 사용자가 취하는 임시방편(Workaround)을 핵심 요소로 여겨요.
그래서 어떤 설문조사로도 발견하지 못할 것들을 일관되게 보여주는 거예요.
사람들은 이런 것들을 거의 언급하지 않거든요.
- 당연하게 여기는 단계들
- 싫어하지만 의존하는 도구들
- 시간이 지나면서 만들어진 단축키들
직접 지켜봐야만 보이는 것들이에요.
맥락 조사를 비유하면, 요리 레시피를 듣는 것과 실제로 부엌에서 요리하는 모습을 지켜보는 것의 차이와 같아요. 레시피에는 “양파를 볶는다”라고 한 줄이지만, 실제 부엌에서는 칼이 무뎌서 양파를 힘겹게 자르고, 팬이 하나뿐이라 순서를 바꾸고, 아이가 부엌에 들어와서 잠시 중단하는 모습이 보이죠. 이런 현실의 디테일이 더 나은 프로덕트 결정의 재료가 돼요.
2) 맥락 조사의 네 가지 원칙
맥락 조사는 단순히 “따라다니며 관찰하기”가 아니에요. 네 가지 핵심 원칙이 있어요.
| 원칙 | 초점 | 왜 중요한가 |
|---|---|---|
| 맥락(Context) | 사용자의 실제 환경에서 일이 어떻게 일어나는지, 주변 상황과 순서, 상황적 제약을 포함하여 파악 | 실제 환경 없이는 중요한 제약과 우회 방법이 사라져서 이해가 불완전 |
| 파트너십(Partnership) | 사용자를 전문가로, 리서처를 학습자로 대하며 관찰과 즉석 질문을 통해 진행 | 실제 맥락은 실제 작업 중에 드러나며, 이것이 질적 데이터의 신뢰성을 높임 |
| 해석(Interpretation) | 관찰된 행동에 의미를 부여하여 가설을 세우고 사용자와 함께 검증 | 가정과 사용자의 실제 의도에서 벗어난 과잉 확신적 결론을 방지 |
| 초점(Focus) | 관찰 시작 전에 명확한 작업, 워크플로우, 문제 영역을 정의 | 명확한 초점 없이는 관찰이 노이즈로 변하고 인사이트가 의사결정 가치를 잃음 |
이 네 가지 원칙이 함께 작동하면서, 관찰이 실제 작업에 기반하고, 신중하게 해석되며, 명확한 목적을 가지고 수집되도록 보장해요.
이 원칙들을 여러 세션에 걸쳐 따르면, 맥락 조사는 개별 일화를 넘어서 일이 실제로 어떻게 이루어지는지에 대한 구조적 패턴을 드러내줘요.
| 맥락 조사가 드러내는 것 | 설명 |
|---|---|
| 워크플로우 | 우회와 반복을 포함한, 사용자가 실제로 취하는 행동의 순서 |
| 도구와 산출물 | 작업 완료를 위해 의존하는 기기, 소프트웨어, 메모, 우회 방법 |
| 환경 | 행동을 형성하는 물리적·사회적 조건 |
| 패턴 | 어피니티 매핑(Affinity Mapping) 같은 종합 방법을 통해 여러 사용자에게서 확인되는 반복적 행동과 문제점을 파악 |
3) 관찰과 해석의 차이, 그리고 현실이 지저분한 이유
사용자 리서치에서 가장 중요한 구분 중 하나는 관찰(Observation)과 해석(Interpretation)의 경계예요.
| 차원 | 관찰 | 해석 |
|---|---|---|
| 정의 | 리서치 중 직접 보거나 듣는 것 | 관찰한 것에 부여하는 의미나 설명 |
| 성격 | 사실적, 구체적, 검증 가능 | 가설적, 가정적, 검증이 필요함 |
| 예시 | “사용자가 제출 전에 데이터를 스프레드시트에 복사한다” | “사용자가 시스템을 신뢰하지 않는다” |
| 리스크 | 낮음 | 높음 (거짓이 사실로 취급될 경우) |
같은 관찰이 여러 해석을 만들어 낼 수도 있어요. 검증 없이는 해석이 쉽게 가정으로 그치는 경우도 많아요.
예를 들어볼게요.
관찰: 사용자가 제출 전에 데이터를 스프레드시트에 복사한다.
가능한 해석들
- 규정 준수를 위해 외부 기록이 필요하다
- 상사가 백업을 요구한다
- 시스템이 타임아웃되기 때문이다
- 과거 오류 경험이 조심스럽게 만들었다
이 해석들이 확인되기 전까지는 추측에 불과해요.
그렇기 때문에 리서처들은 맥락 기반 리서치가 불편하다고 말하곤 해요.
- 워크플로우가 비일관적이다
- 행동이 비효율적이다
- 이유가 감정적이거나 정치적이다
이것이 실제 업무의 “복잡하고 지저분한 진실”이에요.
하지만 이 지저분함은 문제가 아니에요. 좋은 프로덕트 결정의 원재료예요. 깔끔한 이야기는 보통 나중에 오거든요.
현실이 먼저예요.
다음 편에서는 맥락 조사로 수집한 데이터를 팀이 함께 사용할 수 있는 공유된 산출물로 전환하는 방법, 즉 맥락 기반 디자인(Contextual Design)을 살펴볼게요.