주니어 PM의 유저 리서치 - 1편
설문조사, AB Test
01. 유저 리서치가 필요할 때
앞으로 두 편에 걸쳐, 제가 유저 리서치를 직접 기획하고 실행하면서 주의했던 점과 새롭게 배운 점을 기록해보려고 합니다. 학교에서 이론으로 유저 리서치를 배울 때 (부끄럽지만) '이거 너무 당연한 거 아닌가'라고 호기롭게 생각했던 것들이 있습니다. 내가 매니징하는 제품이 생기고, 실제로 고객들을 만날 기회를 꾸려나가면서- 과거의 내 생각이 자만이었구나 느꼈습니다.
일단 유저 리서치 조직이 별도로 있지 않은 이상- 업무에서 유저 리서치를 위한 시간을 내는 것은 생각만큼 아주 자연스럽거나 쉬운 일은 아니었습니다. 얼핏 보면, 제품의 변화를 만들기도 전에 약간은 주춤하는 것 같은 보수적인 행동처럼 비춰질 수도 있고 / 유저 리서치를 통해 알아내고자 하는 것이 분명하지 않은 경우 실제로 제품 개발에 시간적인 병목을 주기도 하기 때문입니다. (고객도 나도) 어렵게 시간 내서 리서치를 진행했는데 제품 개발에 단서는 커녕 오히려 혼란만 주는 의미없는 결과를 얻고 싶지 않다면, 어떤 문제의 단서를 찾고 싶은 것인지 / 어떤 가설을 검증하고 싶은 것인지부터 정해야 합니다.
문제 해결을 위한 가설을 열거해보고, 지금 가진 정보만으로는 가설 검증이 어려울 때 유저 리서치를 진행했습니다. 각 방법론의 중요한 원칙이나 가이드는- 잘 정리되어 있는 다른 자료가 많고 아직 제가 스스로 정보를 만들 수 있는 단계는 아니라고 생각해, 이번 글에서는 각 방법론별로 실무를 진행하면서 경험했던 소소한 실패와 러닝을 소개하려 합니다.
참고로 저는 유저 리서치 방법론을 익힐 때 (전공 공부와 함께) 아래 자료를 공부했습니다.
*개인적으로는 영문 번역이 조금 어색하게 느껴지는 문장들도 있어 술술 읽기에는 조금 아쉬웠습니다.
*리서치 결과를 토대로 액션이 기획될 수 있도록 하는 가이드나 UX 분석 전문가에게 요구되는 역량 등 유저 리서치 본론 진행 외에도 더 총괄적인 관점으로 UX 리서치를 이해하는 데에는 도움이 된 책입니다.
02. 설문조사
(1) 리서치 운영 및 결과 활용에 필요한 정보까지 꼼꼼하게 받기
설문 결과에 대한 활용 동의나, 리워드 지급을 위한 필수 입력 정보가 반드시 포함되어 있어야 합니다. 아무래도 가설 검증에 필요한 질문 위주로 설문을 검토하다보니 이렇게 리서치 운영에 필요한 정보가 다소 부수적으로 느껴져 놓쳐지는 경우를 종종 보았던 것 같은데요. 설문조사는 대규모 인원을 대상으로 진행되는 경우가 많기 때문에, 이런 필수 정보를 나중에 받으려면 응답자 특정이 쉽지 않습니다. 그래서 저는 가급적 운영상 필요한 정보까지 한번에 받을 수 있는 설문을 기획하려고 노력합니다. 물론! 응답자의 집중력을 해하지 않는 위치에 조심스럽게 배치하는 편이며, '나중에 이런 정보도 필요하겠지'라는 생각으로 포괄적인 동의나 과한 개인정보를 요구하는 것은 절대 금지라는 사실을 인지하며 매우 주의하고 있습니다.
(2) 패턴을 찾기 위한 준비 하기
저는 개인적으로 설문조사를 '가설 추리기' 정도의 목적 위주로 활용해왔기 때문에 설문조사의 문항을 설계할 때에는 정교함보다는 패턴화를 우선시했습니다. N개의 응답을 N개의 결론으로 해석할 수는 없기 때문입니다. 결국 이 안에서 패턴을 찾아 수렴을 시켜야 합니다. 응답을 다 받은 후에야 패턴화를 준비하면 막막한 경우가 많았습니다. 그래서 설문지 링크를 배부할 대상, 즉 설문 응답 후보군을 선정할 때부터 일종의 그룹화를 했습니다. 예를 들어 [N개월 내 구매 이력이 M건 이상인 고객]과 [N개월 내 구매 이력이 0건인 고객]에 대한 표본을 따로 추출해 응답도 따로 보관합니다. 그룹의 기준은 가설을 따랐습니다. 가설이 틀렸다면 그룹 간 응답에 차이가 거의 없을 것이고, 있다면 그룹 간 응답에 유의미한 차이가 보이겠지요!
(3) 응답자의 집중력을 고려해 문항 구성하기
하필 가장 궁금한 것이 많을 때 설문을 진행하는 경우가 잦다보니, 질문 초안을 구성해보면 양이 상당합니다. 질문의 양을 줄이는 절차를 반드시 거쳤습니다. 사용자가 자신의 이야기를 들려주기 위해 흔쾌히 설문 시작을 클릭한 경험을 망치고 싶지 않았기 때문입니다. 경우에 따라 다르지만 대부분은 평균 3분 이내 응답할 수 있는 양을 기준으로 질문을 추렸습니다. ('그냥 궁금한 것'이 아니라 '가설' 위주로 질문을 추리다보면 불필요한 질문이 생각보다 많았다는 걸 깨닫게 되기도 합니다) 더불어 응답자가 짧은 시간 동안 몰입해서 집중력 있게 응답할 수 있도록- 질문 간의 연관성을 고려해 질문 순서를 구성했습니다. 질문 A에 응답하기 위해 떠올린 경험이 질문 B의 구체적인 응답에 도움이 될 것 같으면 A 뒤에 B를 배치하는 식입니다.
03. AB Test
(1) 실서버 배포 직후에도 로그 데이터 정상 수집 여부 꼭 확인하기
간혹 A-B안의 UI 간 차이로 인해 동일한 이벤트 또는 동일한 속성으로 집계하는 것이 어려울 때가 있습니다. 예를 들어 동일한 내용이 A안에서는 버튼, B안에서는 태그 의 형태로 표기되고 있다면 A안에서 button_text, B안에서는 tag_text 속성으로 기재가 되겠지요. 이런 경우 실험 설계를 위해 로그 추가를 요청드리게 되는데요. 설계 후 실배포를 하기 전에 당연히 테스트 환경에서 A안, B안 각각의 이벤트 집계 정상 여부를 확인하지만- 실서버 배포 직후에는 모종의 이유로 로그가 집계되지 않는 경우가 있습니다. 이런 경우를 방지하기 위해 실서버 배포 직후에도 반드시 플로우를 타보아야 하고 특히 데이터 수집이 정상적으로 되고 있는지를 확인합니다. 이 절차를 패스하면- (B안에서 분자 이벤트가 집계가 안 된건데) 'A안이 B안보다 +90% 좋네요!' 라는 처참한 해석에 즐거워할 수도 있습니다. 저희 팀은 사용자 로그 분석에 Amplitude를 사용하고 있어서, 로그를 즉시 확인하기 위한 방법 중 하나로 아래 확장 프로그램을 사용하고 있는데요. 다른 분들께 참고가 되실까 하여 남겨둡니다. 이벤트 발생시 우측 상단에 로그 이벤트가 바로 적재되기 때문에 QA시에 매우 용이합니다.
(2) 흔들리지 말고 최소 실험 기간 지키기
AB Test 를 시작하고 나면 결과 데이터가 리프레쉬되는 1시간 간격으로 계속 데이터를 새로고침하고 싶은 욕구가 스멀스멀 차오릅니다. 중간 확인도 공유도 모두 좋지만, (가드레일 지표가 무너지지 않는 이상) 실험 전에 설정한 최소 실험 기간을 채우기 전에는 가급적 소결을 내리지 않는 편이 좋다는 것을 배웠습니다. 예를 들자면 이렇습니다. 월요일에 시작한 실험을 수요일 즈음 펼쳐보면, A안이 이기고 있는 것처럼 보입니다. 하지만 사실은 주 초반에 교육 사이트를 찾는 고객은 헤비 유저일 가능성이 높습니다. 그래서 이 사이트에 기대하는 '익숙한 안'이 더 강하게 있고, 그래서 낯선 B안에 대한 거부감이 더 큰 것일 수도 있습니다. 이런 경우에는 요일 지수를 평준화해줄 최소 실험 기간이 필요하겠지요. 배포 즉시 보여지는 반응에 자꾸만 관심이 가는 건 어찌 할 도리가 없겠으나 그런 기대/실망으로 인해 제품 실험에 나의 주관을 더하는 일은 가급적 피할 수 있도록 노력합니다.
다음 편에서는 정성적인 유저 리서치 방법 (유저 인터뷰, 관찰) 을 활용하며 배웠던 점을 기록하겠습니다. 2주 뒤에 만나요!
