당신의 유저 리서치는 틀리지 않았습니다.
우리 애 한테 왜그래여!! 틀린 건 리서치가 아니라...읍읍
애정하고 애용하는 채널 EO플래닛에 올라온 리서치 관한 글을 보고 마침 리서치에 대한 생각을 정리하고 있던 나는 (또 요즘 한가하기도 하고?) 정독을 해 보았다. 그리고 나서 응?????? 하는 마음에 몇자 적어보려고 브런치를 켜 보았다. 해당 링크를 요약하면,
당신의 유저리서치가 틀린 이유
1. 유저는 무엇을 불편해할까? 잘 모르겠으니까 우선 만나보자!
2. (쿠팡이라면,) 쿠팡을 이용해 본 사람들 중에 참여할 사람을 모아보자!
3. 앱 사용에 있어서 불편한 점이 있는지 인터뷰로 물어보고 개선할 점을 찾아보자!
다 맞말이지 않나..? �
물론 이후 글을 읽어보면 왜 리서치를 하는지, 누구에게 / 어떻게 물어봐야하는지 등
'구체적인 가설에 기반하여 신뢰도/타당도 높은 적확한 리서치'가 필요하다는 것에는 동의할 수 있었다.
그런데 왜 '틀렸다'라고 표현한 걸까. 그 부분이 계속 신경이 쓰였다.
리서치에서 '틀렸다'고 말할 수 있는 것
'틀렸다'는 '셈이나 사실 따위가 그르게 되거나 어긋나다'라는 뜻이라고 한다. 따라서 리서치에서 '틀렸다'는 것은 옳지 못한 방법으로 데이터를 수집했거나(신뢰도/타당도의 결여), 수집된 결과를 잘못 해석한(1종/2종 오류) 경우에 사용할 수 있는 표현일것이다.
또한 사용자/고객을 일단 만나야하는 탐색적 리서치가 필요한 시점이 있다. 이 리서치는 광범위하고 포괄적인 주제를 다루며, 우리 제품이 맞닥뜨린 상황이나 현상을 총체적으로 이해하는데 그 목적이 있다. 가령, 다문화가정 내 10세 이하 아이들의 카카오톡 사용 행태를 조사한다고 해보자. 어떤 식으로 조사를 시작하게 될까? 긴 데스크 리서치로 가설을 세울 시간에 먼저 만나보고 이런저런 대화를 나눠 보는 것이 더 빠르고 많은 정보를 얻을 수 있을 것이다. 거기서 추가적으로 생기는 질문들도 있을 것이고.
무엇보다 사용자/고객에게 던지는 '무엇이 불편한가요?'라는 질문은 틀린 것이 아니다.
물론 인터뷰 내내 A기능의 불편한 점은 무엇인가요 > B기능은요? > C는 어때요? 식으로 마치 서베이 하듯이 시간을 소모하는 것은 바보같은 짓이겠지만, 큰 질문부터 디테일한 질문으로 이동하는 과정에서 던지는 '무엇이 불편한가요? 그 상황에 대해 자세히 말씀해주세요'라는 질문은 경험상 꽤 효과적이다.
단, 불편하다/하지않다 라는 견해에 집중하기 보다는 왜 그렇게 생각했는지 그 이유에 대해 집중 해야한다는 것은 다들 알고 계실 터.�
리서치에 대한 오해가 '틀린' 리서치라는 인식을 낳았다.
리서치에 대한 다양한 오해가 있지만, 본문에 언급된 사용자를 직접 만나 이야기를 들어보는 대면 인터뷰의 경우 리서처가 현재 프로덕트의 답을 찾아 올 것이라는 믿음이 특히 강하다. 그래서 리서치 결과를 기반으로 제품을 만들고 릴리즈 했을때 그 결과가 좋지 않았을 경우 회고하는 과정에서 '그 리서치는 틀렸어' 라는 평가와 인식이 온다고 생각한다.
하지만 인터뷰는 결코 답을 알려주지 않는다. 전체 모집단을 대상으로 한 코호트 리서치도 아니고 샘플링에 의한 오류의 위험이 상존할 수 밖에 없는 방법이다. 오히려 그 샘플에 대한 깊고도 깊은 이해를 목적으로 하는 것이 인터뷰의 강점을 살릴 수 있는 방향이다. 하여, 인터뷰를 일단 나가면 사전에 작성했던 질문지는 잊어라! 거기 있는 모든 질문의 답을 얻어올 필요 없다. (그건 서베이의 역할이지) 제품에 도움이 될 만한 사례/용례를 맨틀을 지나 외핵을 거쳐 내핵까지, 깊고 깊~~~게 파서 사용자/고객의 주변 모든 정황까지 얻어오는 것을 목적으로 하라. 5 whys는 그래서 필요한 것이다.
또한 위와 같은 곳일수록 리서치를 대규모/일회성으로 수행하는 경우가 많다. 제품 사이클 상 적게는 한 달, 길게는 반 년 이상을 1회성 리서치 결과에 기대어 진행하는 것이다. 그래서 이것의 폐해를 해결하고자 LEAN이나 Sprint 같은 방법론이 등장했는데, 이런 방법론에서 리서치는 결과를 내는 것이 목적이 아니라 골에 도달하기 위한 과정이며 팀의 학습 데이터로 여겨진다. 그래서 사용자를 소위 Quick 'n Dirty로 자주 만나는 것이 더 빠르고 안전하게 목적지에 도달하는 방법으로 소개되고 있다.
결론 - 여러분의 리서치는 틀리지 않았다. 틀린 건 제품팀(우리)이지.
숫자로 모든 것을 판단할 수 있는 체계를 갖춘(혹은 갖췄다고 알려진) 쿠팡같은 곳을 제외하면 결국 인터뷰와 같은 질적 리서치의 미덕은 제품팀을 얼마나 사용자의 상황과 니즈에 깊게 공감시켰는가 일 것이다.
결국 제품을 만드는 것은 제품팀이며 리서치는 그 일부분일 뿐이다. 또한 리서치로 모든 것의 정답을 알아 낼 수도 없다. (그럴 수 있었다면 왜 수 많은 기업은 실패하는가) 그렇기에 제품을 만들며 만나는 수 많은 의사결정 포인트에서 사용자를 최대한 구체적으로 떠올릴 수 있게만 해도 리서치로써, 리서처로서의 역할은 충분했다고 생각한다.
어휴 교황 진짜 노답이다~~ 하면서 이 말을 했을 것 같다. 리서치의 부담을 내려놓고 더 많이 사용자를 만나고 더 많이 팀에 공유하자.
모든 팀원들이 가장 구체적으로 우리 제품의 사용자를 상상할 수 있게 만들자.
여러분의 리서치는 틀리지 않았다. 모두 화이팅�
