주니어 PM의 유저 리서치
사용자의 단서를 획득했다.
프로덕트를 판매하고 개선하는 모든 과정에서는 사용자에 대한 이해가 필수적입니다.
유저 리서치가 당연하고 사소한 절차라 생각했던 때도 있었으나 고객과의 접점이 늘어난 지금, 과거의 오만함을 반성하게 됩니다.
유저 리서치가 필요한 이유는 실제 사용자가 겪고 있는 문제를 뾰족하게 정의하기 위함인데요.
궁극적으로 우리는 우리에게 필요한 기능이 아닌 고객이 필요로 하는 제품을 만들어야 하기 때문입니다.
오늘은 개인적으로 제품 개발, 개선 단계에서 가장 많이 사용하는 리서치 방법론들에 대해 다뤄보려 합니다.
0. 가설 설정
본격적인 리서치를 진행하기 전 가장 먼저 검증하고자 하는 가설을 설정합니다.
저의 경우 가설 검증을 위한 데이터가 충분하지 않은 상태에서 주로 유저 리서치를 진행하곤 하는데요 -
이러한 상태에서 리서치를 진행하는 경우, 의사 결정에 소요되는 시간이 불필요하게 길어지거나 방향성이 흔들리기 쉽기 때문입니다.
개인적으로 초기 단계에서는 예상되는 가설을 몇 가지로 정리해 둔 후, 리서치를 통해 소거하는 방식 또한 적절하다고 느꼈는데요. 예를 들면, 인터뷰나 설문 조사를 통해 나타나는 패턴을 기반으로 가장 파이가 큰 가설을 선택하는 방식입니다.
1. 설문 조사
가장 범용적으로 활용되는 리서치 방법 중 하나로, 대량의 데이터를 얻을 수 있다는 장점이 있습니다.
(1) 진행 및 활용 동의
리서치 진행 및 이후의 결과 활용에 필요한 정보, 이에 대한 활용 동의 항목은 필수적입니다.
묻고 싶은 질문들로 항목을 구성하다 보면 놓쳐지기 쉬운 항목일 수 있으나, 가장 중요한 항목이기도 합니다.
(2) 그룹화 기반으로 항목 설계하기
개인적으로는 가설을 추려내는 단계에서 설문 조사를 주요하게 사용하는데요. 이미 개인화된 상태의 수많은 답변이 쌓여 있는 상태에서 가설을 수립하는 일은 쉽지 않기 때문입니다.
따라서 설문 설계 단계부터 설문 항목을 그룹화하여 구성하고자 노력하고 있는데요, 이때 항목은 가설을 따르게 되는 형식입니다. 만약 코호트별 응답에 있어 뚜렷하게 차이를 보인다면 해당 가설을 따라 이후의 액션 아이템을 세워나갈 수 있어, 방향성을 정립하는 데에 도움이 되기도 합니다.
(3) 필수적인 항목들로 구성하기
가장 묻고 싶은 것이 많은 시점 진행되는 리서치이다 보니, 설문의 길이도 길어지기 쉬운데요 -
사용자의 응답에 허들이 되지 않도록 불필요한 질문을 추려내는 단계를 반드시 거칩니다.
이때 판단 기준은 '가설 검증에 필수적인 질문인가?'로 두고 있는데요, 단순 궁금증에서 파생된 질문들이 생각보다 많아지기 쉽기 때문입니다.
동시에, 짧은 시간 몰입을 이어갈 수 있도록 항목의 배치나 흐름을 점검합니다.
저 또한 긴 호흡의 설문에서 쉽게 피로감을 느끼기에, 유입된 유저가 긍정적인 마음으로 개인의 경험을 솔직하게 작성하고 제출 완료까지 이어갈 수 있도록 구성하고자 노력하고 있습니다.
마지막으로는 직접 설문에 응답해 보며 어색한 점은 없는지, 제출까지 문제없이 가능한지에 대해 최종적으로 확인한 후 실제 설문을 진행합니다.
2. 유저 인터뷰
설문 응답자 중 의견을 상세히 남겨주신 분들, 혹은 유관 코호트를 대상으로는 인터뷰를 요청드리기도 하는데요 - 설문 조사가 가설을 추려내는 목적이었다면, 유저 인터뷰는 페인 포인트를 분석하며 가설을 깎아내는 단계라 볼 수 있을 것 같습니다.
저의 경우 각 코호트별로 약 2~3명 정도를 모시는데요, 동일한 코호트에 속하더라도 느끼고 있는 페인포인트는 개인별로 달라질 수밖에 없기 때문입니다.
그중 공통적으로 언급되는 페인포인트를 제품의 핵심 기능으로, 그 외의 내용은 제품의 구성을 고민하는 데에 참고합니다.
스티브 잡스의 '사람들은 그것을 보여줄 때까지 자신들이 무엇을 원하는지 모릅니다.'라는 말처럼, 리서치를 통해 즉시 확실한 답을 즉시 얻어내는 것은 쉽지 않습니다.
따라서 여러 단서를 얻어내는 것이 특히 중요한데요, 이를 위해 질문자의 발화는 줄이고, 인터뷰 대상자가 더 많은 이야기를 할 수 있도록 질문을 구성합니다.
유저 인터뷰의 경우 면밀한 소통이 가능하다는 장점이 있기에, 큰 범위의 질문들을 제시하고 그 이유에 대해 물어보며 사용자를 관찰하는 방식으로 인터뷰를 진행하려 합니다. 동시에 솔직한 의견을 전달 주셔도 괜찮다는 이야기를 함께 전해드리며, 충분한 안정감을 드리려는 나름의 노력을 하기도 하고요 -
3. AB test
제품을 출시한 후에는 크고 작은 개발건들의 임팩트 측정을 위해 AB 테스트를 진행합니다.
AB 테스트란 둘 이상의 버전을 비교해 실험을 진행하는 방법론으로, 목표 지표를 측정하여 가설을 검증하기에 좋은 방법 중 하나입니다.
(1) 최소 실험 기간 지키기
테스트가 진행되는 동안은 결과에 대한 궁금증으로 가득 차 있기 마련인데요 -
가드레일 지표가 무너지지 않는 이상, 실험 전 설정했던 최소 실험 기간을 지키는 것이 좋습니다.
대상의 성격에 따라 행동 특성이 차이 날 수도 있고, 모수가 충분히 확보되지 않은 상태일 수 있으니 지표를 평준화해 줄 수 있는 시간이 필수적이기 때문입니다.
배포 후 유저들의 즉각적인 반응이 궁금한 것은 당연한 것이니, 중간중간 상황을 확인하며 실험의 안정성을 파악합니다.
(2) ‘잘’ 공유하기
ABT 가 종료되면 팀원들 (제게는 스쿼드분들) 에게 결과를 공유하며 마무리합니다.
ABT 진행 후 루틴동일한 결과이더라도 관점에 따라 해석 방향성이 달라질 수 있기에, 의사결정 배경을 충분히 전달하는 것 또한 중요합니다. 상단 이미지에는 포함되지 않았지만, A/B안 각각 참고 가능한 이미지가 있다면 함께 첨부하는 것도 이해에 도움이 됩니다.
(3) 승패보다는 인사이트에 집중하기
하나의 가설을 검증하기 위한 실험이 진행될 때마다 PM, 디자이너, 개발자는 더 좋은 해결 방법에 대해 치열하게 고민합니다. 그렇기에 B안의 승리를 바라는 마음도, A 안이 이기는 경우 실망하는 마음도 당연한 마음일지 모릅니다.
개인적인 기대나 실망이 해석에 영향을 미치지 않도록 노력하는 것은 물론, 매 실험의 결과와 무관하게 얻을 수 있었던 인사이트를 정리하고자 노력합니다. 결과와 무관하게 얻을 수 있는 인사이트는 늘 존재하니까요!
유저 리서치는 늘 긴장되지만 일의 의미를 다시금 실감하게 되는 자리이기도 합니다.
여러 핑계들로 사용자를 마주하는 것에 소홀하지 않기를 다시 한번 다짐하며, 글을 마무리합니다.
