주니어 PM의 유저 리서치 - 2편
유저 인터뷰, 관찰
지난 글
두 편에 걸쳐, 제가 유저 리서치를 직접 기획하고 실행하면서 주의했던 점과 새롭게 배운 점을 기록하고 있습니다. 설문조사와 AB Test 에 관한 기록은 아래 글을 참고해주세요.
https://brunch.co.kr/@leesy0203/13
01. 유저 인터뷰
사용자와의 대화를 통해 니즈를 파악해나간 경험을 돌아보았습니다. 코로나가 한창 유행일 때에는 ZOOM이나 Google Meet으로 진행하는 비대면 인터뷰를 주로 진행했고, 그 후에도 시간 절약을 위해 종종 비대면 방식을 선택했습니다. 다만 질문의 난이도와 양을 고려해 사용자의 집중력이 필요하다고 판단되면 대면으로 뵙기도 했었는데요. 대면 인터뷰를 진행하다보면 '서비스 화면 뒤에 내가 있듯 데이터 뒤에 사용자가 있구나'라는 게 좀 더 생생하게 느껴지기도 합니다. 그럴 때, 내가 일하는 태도의 진정성을 곱씹어보기도 했던 터라 저는 사용자를 직접 만나뵙고 인터뷰하는 자리를 좋아하는 편입니다.
인터뷰는 준비된 질문을 하는 자리가 아니라 대화를 하는 자리
너무나 당연하다고 생각했지만 결코 지키기 쉬운 원칙은 아니었습니다. 대면 전에 문자로 연락을 주고 받을 때는 서로 부담이 없었지만 막상 대면하고나니 첫 만남의 어색함이 생각보다 크다든지, 지각으로 인해 인터뷰 시작이 지연된다든지- 하는 일이 생기면 마음이 급해졌습니다. 문장 사이 필러를 충분히 넣어 나름 자연스러운 대화를 이끌었다고 생각했는데, 녹음된 걸 들어보니 부끄러웠습니다. 질문 1 에 대한 답변에 기반해 1-2, 1-3, 1-4.. 를 꼬리 질문하며 궁금했던 바를 해결했어야 했는데 질문 1-2 정도까지만 가고 질문 2 로 넘어가려 했기 때문이었습니다. 같은 실수를 반복하지 않기 위해 채택한 방법은 크게 2가지입니다.
첫째, 인터뷰 진행의 역할 분배하기
자연스러운 대화를 위해 1:1 대화가 꼭 필요할 때도 있지만, 가급적 인터뷰 기록 1명, 인터뷰 진행 1명으로 역할을 분담하는 것이 도움이 되기도 합니다. 사용자가 했던 답변 중에 중요해 보이는 것을 기록도 하고 다음 질문도 하고 눈도 맞추려고 하다 보니 마음이 급해지는 것을 방지할 수 있습니다. 물론 인터뷰 기록을 위해 사람이 아니라 녹음기를 사용할 수도 있습니다. 하지만 녹음본의 STT(Sound-To-Text) 결과가 깔끔하지 못한 경우도 더러 있고, 지금 이 답변이 우리가 인터뷰 전에 세운 가설에 부합한지의 여부를 판단하며 기록하는 것이 필요해 저는 이 역할을 사람이 하는 것이 바람직하다고 생각합니다. 녹음기는 충실한 보조 도구로 사용하면 좋고요. '인터뷰 결과를 활용해 기획할 기능의 잠재 제작자'인 디자이너 또는 개발자 분들과 인터뷰에 들어가면서 인터뷰 진행에도 도움을 얻고 & 사용자의 RAW한 반응을 스쿼드 내에 전파했던 것이 인상적인 기억으로 남아있습니다.
둘째, 인터뷰 질문은 불렛 단위로 간단하게 준비하기
중요한 발표를 준비할 때 발표시 말할 모든 문장이 다 적힌 '대본'이 아니라 목차별 핵심 내용이 간결하게 적힌 '큐카드'를 활용해보라는 팁과 같은 맥락입니다. 인터뷰 질문 15개를 문장 단위로 다 적는 것이 아니라 인터뷰에서 확인하고 싶은 점만 불렛 단위로 작성해두고, 문장에서 활용하는 표현이나 스타일은 인터뷰 참여자에 맞춰 적절히 변경하는 것이 자연스러운 대화 진행에 큰 도움이 되었습니다. 아래와 같이 인터뷰 참여자의 기본 정보를 미리 전달받고 그에 입각해 불렛 가설의 구체성을 높이는 방식으로 이 방법을 개선해나가기도 했습니다.
인터뷰 직전에 참고한 제 나름의 큐카드(?)02. 관찰
가장 드물게 선택했던 유저 리서치 방법론이기도 합니다. 시간과 비용이 많이 들기도 하고 원활한 진행을 위해 제어해야 하는 환경 변수도 복잡한 방법이기 때문입니다. 세 번 정도에 그친 경험이긴 하지만- 배운 점의 농도는 짙은 경험이었습니다. 1년 전 제가 담당했던 제품은 [정부 사이트에 접속해 교육비 지원 카드 발급 신청하기]가 결제까지의 전환 퍼널에서 아주 중요한 역할을 했습니다. 전 단계에서 다음 단계로 넘어가는 전환율이 가장 낮은 단계이기도 했습니다. 내부 구성원은 정부 사이트에 대한 이해도가 이미 높은 상태였기 때문에 가설 수립의 한계를 느끼고 직접 사용자의 행동을 관찰하기로 결정했습니다. 그래서 카드 신청 기록 유무에 따라 해당 퍼널을 경험해야 하는 사용자 유형을 나누고, 유형별로 한 분씩 직접 사무실로 모셨습니다. 핸드폰이나 PC로 카드 발급 신청 퍼널을 진행하시는 동안 저희는 다른 방에서 해당 화면을 화면 공유로 관찰하고 > 끝난 후 다시 한 방에 모여 관찰 기록 중 흥미로웠던 점을 추가 질문하는 식으로 사용자 행동을 분석했습니다. 관찰 방법은 '잘 하기'가 참 어려운 방법이었습니다. 배운 점을 공유합니다.
(1) 사용자가 발화할 수 있도록 하자
사람의 행동을 '보는 것'만으로 알아낼 수 있는 사실은 의외로 별로 없다는 걸 깨달았습니다. 이를테면 행동의 이유나 의도를 알 수 없습니다. 어떤 행동을 하는지는 로그 데이터로 파악하는 게 더 쉽고 빠릅니다. 그래서 관찰 이라는 방법을 십분 활용하려면, 사용자가 행동을 하는 동시에 본인이 어떤 단계에서 막히는지 / 어떤 생각을 하고 있는지 등을 직접 말할 수 있도록 하는 것이 중요합니다. '나혼자산다'에 출연한 것처럼요. 하지만 혼자 중얼거리는 것은 당연히 낯선 경험이기 때문에 이걸 자연스럽게 할 수 있도록 유도하는 것이 필요한데요. 저는 가급적 유저 리서치를 할 때에는 편향 방지를 위해 예시를 잘 들지 않는 편이지만, 관찰 전 안내사항을 설명할 때에는 '떠오르는 것들을 모두 말해주세요'의 예시를 보여드렸습니다. 정말 사소한 말, 누구한테 들려주려고 하는 게 아니라 혼잣말이기 때문에 거칠 수 있는 표현 등을 포함한 예시를 통해, 머리를 거치지 않고 떠오르는대로 바로바로 발화해도 괜찮다는 안심을 드리려 했습니다.
(2) 시나리오대로 환경을 세팅해두자
이것은 리서치의 목적에 따라 다를 수 있을텐데요. 리서치 초기 단계에서 사용자의 행동을 폭 넓게 관찰하려는 상황이라면 환경 세팅을 포함한 어떤 개입도 하지 않는 것이 바람직할 것입니다. 하지만 제 리서치의 목적은 'A라는 과제가 주어졌을 때 사용자가 어떻게 행동할 것인가'였기 때문에 A 과제의 착수에 필요한 최소한의 환경을 세팅하는 것이 필요했습니다. 물론 이 최소한의 범위를 어디까지 볼 것이냐도 리서치의 객관성에 영향을 줄 것이며, 이것 역시 리서치의 목적에 따라 적절히 수정이 필요할 것입니다. 처음 관찰 방법론을 적용했을 때, 사용자의 핸드폰에 Figma 앱이 없을 것이라는 생각을 하지 못하고 Figma 프로토타입으로 제작한 퍼널에 참여하시게 유도하려 했던 부끄러운 전적이 있습니다. 직접 사용하시는 핸드폰으로 리서치에 참여해야 사용자의 평소 행동을 관찰하기 유리한 것은 사실이나, 당시에는 관찰 시간을 더 끌 수 없어서 결국 (마침 저희 핸드폰 중에 사용자와 같은 핸드폰 기종이 있어서) Figma 앱이 설치되어 있는 저희 핸드폰으로 참여하시게끔 했던 기억이 납니다. 너무 사소해 부끄러운 경험이지만 이 때 데인(?) 덕분에 같은 실수를 반복하지는 않았습니다.
이번 글을 포함해 총 두 편의 글을 통해, 제가 경험했던 유저 리서치의 방법론별 '다음에는 꼭 염두에 두어야지' 싶은 내용을 정리해보았는데요. 이 기록이 저에게도, 읽어주신 여러분께도 소소하게나마 도움이 되기를 바랍니다.
