<div id="readability-page-1" class="page"><div>UX 리서치에 관심 있는 분들과 커피챗을 하면 듣게 되는 공통적인 질문이 있어요.“토스 UX 리서처는 어떤 리서치 방법론을 쓰나요?”“토스 UX 리서처는 리서치를 처음부터 끝까지 혼자서 하는 구조인가요?”이 질문을 들었을 때 딱 잘라 답을 드리기 어려우면서도, 언젠간 시원하게 풀어보고 싶다는 생각이 있었어요. 이 글을 통해 토스의 UX 리서처는 어떤 방법론을 쓰는지, 리서치를 처음부터 끝까지 혼자서 도대체 어떻게 해나가는지 알려드릴게요.<h3 id="c3ed8db2-7a8a-4cfb-b47a-4e73049cfa9f">토스 UX 리서처가 쓰는 리서치 방법론 </h3>이 글을 읽고 계신 독자님은 어떤 방법론을 알고 계신가요?아마도 조사방법으로는 IDI(In-Depth Interview), FGI(Focused Group Interview), UT(Usability Testing), 혹은 Diary Study가 많이 언급되는 것 같고, 분석 방법론으로는 Affinity Diagram이나 Persona도 들어보셨을 거에요. 아, User Journey Map도 자주 언급되는 것 같고요. 그 중에서 토스가 선택한 방법론은, 바로 러닝쉐어에요.사실 UX 리서치 방법론은 취사선택하는 ‘도구’라기보다는 ‘토대’에 가깝다고 생각해요. 마치 요리사가 되었다면 기본적인 조리법을 알고 있는 것은 너무나 당연한 일인 것처럼요. 잘하는 요리사가 되려면 TPO에 따라 어떤 요리가 맞을지 잘 제시하고, 어떤 재료나 상황 속에서도 주어진 조건을 잘 활용해서 성공적인 요리를 제공해야겠죠. 그런 요리사가 있다면, 그 사람이 볶음 요리를 주로 하는지 국물 요리를 주로 하는지는 중요하지 않을 거예요.리서치도 마찬가지로 얻고자 하는 리서치 목표가 뚜렷하고 그 목적에 맞는 결과를 얻을 수 있다면 어떤 방법론을 사용하느냐는 크게 중요한 문제가 아니더라고요. 하지만 UX 리서치 방법론을 이야기하는 아티클이나 책에서는 바로 그 리서치 목표를 어떻게 해야 잘 세우는지는 알려주지 않아요. 또 다양한 조건과 상황 속에서 어떻게 대처해야 할지도요. 그건 결국 그 리서치를 진행할 리서처가 그 케이스에 맞게 세워야 하기 때문이죠. 진리의 케바케(케이스 바이 케이스)라고나 할까요.그렇다면 맥락에 적합한 리서치를 잘 하기 위해서는 어떤 것들을 공부해야 할까요? 
다른 사람의 성공과 실패 사례, 즉 케이스 스터디만큼 확실한 방법도 없을 거예요.<h3 id="8bd80504-2e65-4971-a6e4-198c0fcf49f2">토스 UX 리서처의 위클리 러닝쉐어 코너를 소개합니다</h3>그래서, 토스의 UX 리서치팀에는 리서치의 성공과 실패 사례를 공유하는 러닝쉐어 시간이 있어요. 여기서 ‘러닝’의 범위가 정해져 있진 않으며 작더라도 상관없어요. 리서치를 진행하는 타이밍이나 대상 사용자를 누구로 설정할지, 어떤 설문조사 질문이 유의미하고 유의미하지 않았는지 등 리서치 전체 과정 중의 일부분의 러닝이더라도 다른 업무에 활용해 볼 수 있는 실용성이 있다면 어떤 러닝이든 의미가 있더라고요. 또 이미 다들 아는 내용일 것 같다고 생각되는 러닝도 상관없어요. 암묵적으로 알고 있는 것과 사례를 통해 명시되는 것은 다르니까요. 그간 쌓아왔던 저희 러닝쉐어 중 몇 가지를 소개해볼게요.<h3 id="4446a696-4215-47e7-97c9-25a842f0f47e">#1. 일상적인 서비스는 최소한 1달은 지나고 사용자 의견 체크하기</h3>몇 년 전, 토스에서 홈 화면을 대대적으로 개편한 적이 있었어요. 작고 빠른 개선이 더 익숙한 토스에서는 이때 홈 화면 개편이 꽤 큰 규모의 개편이었어요. 이에 홈 개편을 맡은 팀에서는 개편에 대한 결과와 더 고쳐야 할 점을 빨리 얻고 싶어 하고 있었고요. 그래서 홈 화면이 개편되고 난 바로 다다음날 만족도 설문조사를 발송했죠. 그랬더니 역시나, 다양한 불편 사항들이 쏟아져 나왔어요. 나온 불편 사항들로 가설을 세우고 해당 설문 조사에서 불편함을 표시해 주신 분들께 더 자세한 이야기를 듣기 위해 몇분은 인터뷰에 모시기도 했죠. 어느 날은 만족도 조사 설문에서 보유한 계좌가 요약되어 보여주도록 바뀐 부분이 “매우 불편하다”라고 적어주신 분을 인터뷰에 모셨는데요. 어떤 맥락에서 그렇게 불편하셨을지 자세히 경청할 준비를 하고 인터뷰에 들어갔는데, ‘그땐 그렇게 적었는데 이제는 익숙해져서 괜찮다’고 말씀하시더라고요.한 분이었으면 그럴 수도 있겠다 싶었을 텐데, 불편함을 적어주신 몇몇 분들이 공통으로 설문조사 때와는 온도가 다르다는 것을 알고 나서, 개편 한 달이 지난 시점에 다시 한번 동일한 내용으로 설문조사를 진행해 봤어요. 그랬더니 개편 직후와 비교했을 때 눈에 띄게 극단적인 의견이 많이 줄어들었더라고요. “매우 불편하다”는 의견도, “매우 편리하다”는 의견도요. <figure id="ab1c462d-7313-4c36-91e4-25a9f4c3bc4b"><img src="https://static.toss.im/ipd-tcs/toss_core/live/beba8284-8881-4810-a27e-b14e6933a405/Untitled.png" alt=""><figcaption>홈 개편 직후의 설문 결과와 한달 후의 설문 결과</figcaption></figure>한 달 정도 시간이 지나니 낯선 사용성에 불편함을 느꼈던 분들은 익숙해지기도 하고, 좋다고 느꼈던 분들은 사용하면서 불편한 점을 서서히 발견하기도 하지 않았을까 싶어요. 어쨌든 확실한 것은 유저가 일상적으로 사용하던 서비스의 경우엔 개편 후 초반보다는 어느 정도 사용을 해보고 받는 의견이 더욱 진정성 있다는 점을 알게 되었죠. 이 이후로 개편 이후 사용자 피드백을 받아보고 싶다는 팀이 있으면, 이 이야기를 하면서 서비스의 사용주기를 감안해 사용자가 충분히 사용해 봤을 법한 기간을 두고 그 이후 피드백을 받는 것을 추천해 드리고 있어요. <h3 id="27c75718-2fc2-42b7-ac11-fd06bb9f98d9">#2. “쓸 것 같다”라는 유저의 말은 아무 의미가 없다</h3>UX 리서치에 대해 관심이 있는 분들이라면 이 이유에 대해서 너무 잘 알고 계실 거예요. 하지만 제품이 성공할지 모르는 매우 불확실한 상황에서 출시해 본 경험이 있으시다면, 이 제품을 유저들이 쓸지 알고 싶은 마음에 대해서 너무 잘 이해하실 거고요. 몇 년 전, 토스에서 실험적으로 소셜 기능을 출시한 적이 있었어요. 소셜 기능은 개발에도 많은 공수가 들더라고요. 그렇다 보니 팀에서는 디자인이 어느 정도 완성되었을 무렵 이걸 본 유저들의 반응이 궁금할 수 밖에 없는 상황이었죠. 하지만 유저가 쓸 지 안 쓸지 미래를 예측하는 것이 리서치 목적이 아님을 환기하려 노력하면서 다른 가설을 검증하기 위한 목적으로 인터뷰를 진행했어요. 당시 기억에 남는 인터뷰가 있었는데요. 이 서비스를 눈에 띄게 좋아하시는 분이 계셨어요. 이 서비스를 자주 쓰게 될 것 같다면서 서비스에 대해 매우 긍정적으로 말씀을 해 주시더라고요. 출시일까지 물어보셨던 것으로 기억해요. 그러고 나서 시간이 흘러 서비스가 출시되고, 출시 전 인터뷰를 진행했던 사용자분들께 간단한 의견을 다시 여쭐 겸 추가로 연락을 드려봤어요.그런데, 그 분께서 서비스를 전혀 쓰지 않는다고 말씀을 주셨어요. 그 이유를 여쭤보고 나서, 소셜 서비스는 특성상 실제 현실의 친구가 이 서비스를 사용하는지가 서비스의 매력도보다 더 중요한 요인이라는 것을 깨달았죠. 하지만 인터뷰 당시에는 그런 현실의 요인을 떠올릴 수 있는 환경이 아니니 어찌 보면 자연스럽게 발생할 수 있는 결과였죠. 하지만 이 인터뷰에서 왜 UX 리서처가 “쓸 것 같나요?” 라는 질문을 지양하는지 그 이유를 너무 잘 드러내고 있기에, 이 이야기는 팀원들이 사용자분한테 쓸 것 같냐고 물어보길 원할 때 참고할 수 있게 보여드리는 사례로 활용하고 있어요.이 외에도 온라인 설문조사에서 최대한 진실성 있는 응답을 얻어내는 문항 설계 방법이나 설문조사 발송 타이밍, 인터뷰에서 불편한 점이 없다고만 말씀하시는 사용자분께도 인터뷰를 통해서 이분에게는 어떤 불편점이 있는지 이끌어내는 방법, 정성 조사에서 얻은 가설을 실제 서비스 데이터를 통해 검증하는 방법 등.. 다양한 러닝을 공유해 왔어요. 나머지 러닝에 대해서는 기회가 된다면 다음에 소개해 드릴게요.<h3 id="0f8f6a3f-71db-46d4-a4ab-0fc92b3daaa9">러닝쉐어 문화를 만들어가는 방법 </h3>이와 같은 러닝쉐어 문화가 한 번에 만들어졌냐고 하면, 절대 아니에요. 아주 오랜 기간동안 다양한 방식을 테스트해보면서 자리를 잡아 나갔는데요. 그 이유는 위에 소개해 드린 사례들처럼 유의미한 사례가 매주 나오기는 어렵기 때문이에요. 그러다 보니 사례가 모이기만을 기다리다가 오랫동안 러닝쉐어의 공백이 생기기도 했어요.그래서 최근에는 이 시간에 리서치 방법을 공부해 보고 팀원들한테 소개하는 스터디를 하기도 하고요. 팀원들과 토의해 보고 싶은 아젠다를 가져오기도 하고 있어요. 러닝쉐어만 하는 시간으로 여겼을 때는 팀원들이 사례를 선정하는 데 부담을 느끼기도 했는데, 러닝쉐어 외에 다뤄볼 이야기들을 넓혔더니 러닝쉐어가 더 활발해지더라고요. 특히 ‘이 주의 아젠다’ 코너를 시작한 것이 효과적이었어요. 이 코너는 UX리서치를 하면서 사소하더라도 은근 고민하게 되는 포인트를 가볍게 토론하기 위한 목적으로 시작했는데요. 토론하다 보면 다른 팀원의 고민에 조언을 주게 되기도 하고, 나의 업무방식을 되돌아보기도 하고, 기존 나의 방식에서 더 효율적인 방법을 찾게 되기도 하더라고요. <figure id="7e80e706-fe9f-40cf-9506-a3a2253a4c1c"><img src="https://static.toss.im/ipd-tcs/toss_core/live/b79c54ae-08f0-4769-9612-a1d5364e2482/3V5A5473.jpg" alt=""></figure>나만의 고민이라고 생각했던 작은 고민에 대해 다른 리서처 팀원들의 공감 그리고 다양한 관점을 들어볼 수 있을 때 일하는 방식을 되돌아볼 수 있는 기회가 되는 것 같아요. ‘너무 소소한 주제면 어떡하지’ 하는 걱정도 필요 없어요. 팀원들이 소소한 아젠다더라도 늘 너무 진심으로 토론하는 바람에 항상 열띤 토론으로 마무리되거든요. ‘이 주의 아젠다’로 다뤘던 주제들을 일부 소개해 드려요. 여러분은 아래 주제에 대해 어떤 생각을 가지고 계신가요? 한번 같이 일하는 팀원들과 이야기해 보세요. <ul><li id="f83f12d6-88d7-4156-b492-a97088c2bbb5">'컴포넌트가 클릭커블한지'를 검증 할 수 있을까?</li><li id="808c032c-5d53-4aef-bff5-9b197f38014c">인터뷰에서의 '중립성'은 어디까지 지켜야 할까?</li><li id="002e6be9-d18b-4288-a426-a68a8bac5d2a">사용자에게 ‘최근 경험’을 묻기 vs ‘평소 경험’을 묻기</li><li id="0b860571-6ae3-4f89-a16c-24b2740416ae">‘재미’를 검증할 수 있을까?</li><li id="d63dfa42-0592-42c4-97e5-30e27e76620b">아이스브레이킹과 인터뷰 안내를 위한 도입부 질문이 이어지는 인터뷰나 UT를 편향되게 할 수 있다면 어떻게 해야 할까?</li></ul><h3 id="f0327c93-5c34-45e5-acee-9b8867e1d63f">토스 UX 리서처는 리서치의 처음부터 끝까지 혼자서 하나요?</h3>토스의 UX 리서치 방법론에 대해서 시작해서 리서치팀의 위클리 러닝쉐어 문화를 소개했는데요. 제 이야기를 통해 이 질문에 대한 답변을 대신하고 싶어요.리서처가 하나의 리서치 아젠다에 대해서 처음부터 끝까지 그 아젠다에 맞는 리서치 목표와 방법을 설정하고 이끌어 가는 것이 맞다고 생각하고 있어요. 하지만 리서치를 진행하며 드는 고민에 대해서는 찾아볼 수 있는 여러 사례와 식지 않는 토론방이 언제든 열려 있고 이 자리를 어떻게 활용하느냐에 따라 리서치 퀄리티를 얼마든지 높일 수 있어요. 위와 같은 궁금함이 있으셨던 분들께는 리서치에 대한 책임과 권한은 오롯이 맡고 있지만 고민을 나눌 팀이 있기에, 리서치를 ‘혼자 하고 있다’는 생각은 해본 적 없다는 이야기를 드리고 싶어요. 토스의 유저 리서치팀에 관심 있다면, 지금 지원하세요. <a target="_blank" rel="noreferrer noopener" href="https://toss.im/career/job-detail?job_id=5913667003&amp;company=%ED%86%A0%EC%8A%A4%EC%BB%A4%EB%AE%A4%EB%8B%88%ED%8B%B0">UX 리서처 서류 프리패스 전형 (~3/24)</a></div></div>

토스테크

UX 리서치에 관심 있는 분들과 커피챗을 하면 듣게 되는 공통적인 질문이 있어요.
“토스 UX 리서처는 어떤 리서치 방법론을 쓰나요?”
“토스 UX 리서처는 리서치를 처음부터 끝까지 혼자서 하는 구조인가요?”
이 질문을 들었을 때 딱 잘라 답을 드리기 어려우면서도, 언젠간 시원하게 풀어보고 싶다는 생각이 있었어요. 이 글을 통해 토스의 UX 리서처는 어떤 방법론을 쓰는지, 리서치를 처음부터 끝까지 혼자서 도대체 어떻게 해나가는지 알려드릴게요.
토스 UX 리서처가 쓰는 리서치 방법론 
이 글을 읽고 계신 독자님은 어떤 방법론을 알고 계신가요?
아마도 조사방법으로는 IDI(In-Depth Interview), FGI(Focused Group Interview), UT(Usability Testing), 혹은 Diary Study가 많이 언급되는 것 같고, 분석 방법론으로는 Affinity Diagram이나 Persona도 들어보셨을 거에요. 아, User Journey Map도 자주 언급되는 것 같고요. 
그 중에서 토스가 선택한 방법론은, 바로 러닝쉐어에요.
사실 UX 리서치 방법론은 취사선택하는 ‘도구’라기보다는 ‘토대’에 가깝다고 생각해요. 마치 요리사가 되었다면 기본적인 조리법을 알고 있는 것은 너무나 당연한 일인 것처럼요. 잘하는 요리사가 되려면 TPO에 따라 어떤 요리가 맞을지 잘 제시하고, 어떤 재료나 상황 속에서도 주어진 조건을 잘 활용해서 성공적인 요리를 제공해야겠죠. 그런 요리사가 있다면, 그 사람이 볶음 요리를 주로 하는지 국물 요리를 주로 하는지는 중요하지 않을 거예요.
리서치도 마찬가지로 얻고자 하는 리서치 목표가 뚜렷하고 그 목적에 맞는 결과를 얻을 수 있다면 어떤 방법론을 사용하느냐는 크게 중요한 문제가 아니더라고요. 하지만 UX 리서치 방법론을 이야기하는 아티클이나 책에서는 바로 그 리서치 목표를 어떻게 해야 잘 세우는지는 알려주지 않아요. 또 다양한 조건과 상황 속에서 어떻게 대처해야 할지도요. 그건 결국 그 리서치를 진행할 리서처가 그 케이스에 맞게 세워야 하기 때문이죠. 진리의 케바케(케이스 바이 케이스)라고나 할까요.
그렇다면 맥락에 적합한 리서치를 잘 하기 위해서는 어떤 것들을 공부해야 할까요? 
다른 사람의 성공과 실패 사례, 즉 케이스 스터디만큼 확실한 방법도 없을 거예요.
토스 UX 리서처의 위클리 러닝쉐어 코너를 소개합니다
그래서, 토스의 UX 리서치팀에는 리서치의 성공과 실패 사례를 공유하는 러닝쉐어 시간이 있어요. 여기서 ‘러닝’의 범위가 정해져 있진 않으며 작더라도 상관없어요. 리서치를 진행하는 타이밍이나 대상 사용자를 누구로 설정할지, 어떤 설문조사 질문이 유의미하고 유의미하지 않았는지 등 리서치 전체 과정 중의 일부분의 러닝이더라도 다른 업무에 활용해 볼 수 있는 실용성이 있다면 어떤 러닝이든 의미가 있더라고요. 또 이미 다들 아는 내용일 것 같다고 생각되는 러닝도 상관없어요. 암묵적으로 알고 있는 것과 사례를 통해 명시되는 것은 다르니까요. 
그간 쌓아왔던 저희 러닝쉐어 중 몇 가지를 소개해볼게요.
#1. 일상적인 서비스는 최소한 1달은 지나고 사용자 의견 체크하기
몇 년 전, 토스에서 홈 화면을 대대적으로 개편한 적이 있었어요. 작고 빠른 개선이 더 익숙한 토스에서는 이때 홈 화면 개편이 꽤 큰 규모의 개편이었어요. 이에 홈 개편을 맡은 팀에서는 개편에 대한 결과와 더 고쳐야 할 점을 빨리 얻고 싶어 하고 있었고요. 그래서 홈 화면이 개편되고 난 바로 다다음날 만족도 설문조사를 발송했죠. 
그랬더니 역시나, 다양한 불편 사항들이 쏟아져 나왔어요. 나온 불편 사항들로 가설을 세우고 해당 설문 조사에서 불편함을 표시해 주신 분들께 더 자세한 이야기를 듣기 위해 몇분은 인터뷰에 모시기도 했죠. 어느 날은 만족도 조사 설문에서 보유한 계좌가 요약되어 보여주도록 바뀐 부분이 “매우 불편하다”라고 적어주신 분을 인터뷰에 모셨는데요. 어떤 맥락에서 그렇게 불편하셨을지 자세히 경청할 준비를 하고 인터뷰에 들어갔는데, ‘그땐 그렇게 적었는데 이제는 익숙해져서 괜찮다’고 말씀하시더라고요.
한 분이었으면 그럴 수도 있겠다 싶었을 텐데, 불편함을 적어주신 몇몇 분들이 공통으로 설문조사 때와는 온도가 다르다는 것을 알고 나서, 개편 한 달이 지난 시점에 다시 한번 동일한 내용으로 설문조사를 진행해 봤어요. 그랬더니 개편 직후와 비교했을 때 눈에 띄게 극단적인 의견이 많이 줄어들었더라고요. “매우 불편하다”는 의견도, “매우 편리하다”는 의견도요. 
한 달 정도 시간이 지나니 낯선 사용성에 불편함을 느꼈던 분들은 익숙해지기도 하고, 좋다고 느꼈던 분들은 사용하면서 불편한 점을 서서히 발견하기도 하지 않았을까 싶어요. 어쨌든 확실한 것은 유저가 일상적으로 사용하던 서비스의 경우엔 개편 후 초반보다는 어느 정도 사용을 해보고 받는 의견이 더욱 진정성 있다는 점을 알게 되었죠. 
이 이후로 개편 이후 사용자 피드백을 받아보고 싶다는 팀이 있으면, 이 이야기를 하면서 서비스의 사용주기를 감안해 사용자가 충분히 사용해 봤을 법한 기간을 두고 그 이후 피드백을 받는 것을 추천해 드리고 있어요. 
#2. “쓸 것 같다”라는 유저의 말은 아무 의미가 없다
UX 리서치에 대해 관심이 있는 분들이라면 이 이유에 대해서 너무 잘 알고 계실 거예요. 하지만 제품이 성공할지 모르는 매우 불확실한 상황에서 출시해 본 경험이 있으시다면, 이 제품을 유저들이 쓸지 알고 싶은 마음에 대해서 너무 잘 이해하실 거고요. 
몇 년 전, 토스에서 실험적으로 소셜 기능을 출시한 적이 있었어요. 소셜 기능은 개발에도 많은 공수가 들더라고요. 그렇다 보니 팀에서는 디자인이 어느 정도 완성되었을 무렵 이걸 본 유저들의 반응이 궁금할 수 밖에 없는 상황이었죠. 하지만 유저가 쓸 지 안 쓸지 미래를 예측하는 것이 리서치 목적이 아님을 환기하려 노력하면서 다른 가설을 검증하기 위한 목적으로 인터뷰를 진행했어요. 
당시 기억에 남는 인터뷰가 있었는데요. 이 서비스를 눈에 띄게 좋아하시는 분이 계셨어요. 
이 서비스를 자주 쓰게 될 것 같다면서 서비스에 대해 매우 긍정적으로 말씀을 해 주시더라고요. 출시일까지 물어보셨던 것으로 기억해요. 그러고 나서 시간이 흘러 서비스가 출시되고, 출시 전 인터뷰를 진행했던 사용자분들께 간단한 의견을 다시 여쭐 겸 추가로 연락을 드려봤어요.
그런데, 그 분께서 서비스를 전혀 쓰지 않는다고 말씀을 주셨어요. 그 이유를 여쭤보고 나서, 소셜 서비스는 특성상 실제 현실의 친구가 이 서비스를 사용하는지가 서비스의 매력도보다 더 중요한 요인이라는 것을 깨달았죠. 
하지만 인터뷰 당시에는 그런 현실의 요인을 떠올릴 수 있는 환경이 아니니 어찌 보면 자연스럽게 발생할 수 있는 결과였죠. 하지만 이 인터뷰에서 왜 UX 리서처가 “쓸 것 같나요?” 라는 질문을 지양하는지 그 이유를 너무 잘 드러내고 있기에, 이 이야기는 팀원들이 사용자분한테 쓸 것 같냐고 물어보길 원할 때 참고할 수 있게 보여드리는 사례로 활용하고 있어요.
이 외에도 온라인 설문조사에서 최대한 진실성 있는 응답을 얻어내는 문항 설계 방법이나 설문조사 발송 타이밍, 인터뷰에서 불편한 점이 없다고만 말씀하시는 사용자분께도 인터뷰를 통해서 이분에게는 어떤 불편점이 있는지 이끌어내는 방법, 정성 조사에서 얻은 가설을 실제 서비스 데이터를 통해 검증하는 방법 등.. 다양한 러닝을 공유해 왔어요. 나머지 러닝에 대해서는 기회가 된다면 다음에 소개해 드릴게요.
러닝쉐어 문화를 만들어가는 방법 
이와 같은 러닝쉐어 문화가 한 번에 만들어졌냐고 하면, 절대 아니에요. 아주 오랜 기간동안 다양한 방식을 테스트해보면서 자리를 잡아 나갔는데요. 그 이유는 위에 소개해 드린 사례들처럼 유의미한 사례가 매주 나오기는 어렵기 때문이에요. 그러다 보니 사례가 모이기만을 기다리다가 오랫동안 러닝쉐어의 공백이 생기기도 했어요.
그래서 최근에는 이 시간에 리서치 방법을 공부해 보고 팀원들한테 소개하는 스터디를 하기도 하고요. 팀원들과 토의해 보고 싶은 아젠다를 가져오기도 하고 있어요. 러닝쉐어만 하는 시간으로 여겼을 때는 팀원들이 사례를 선정하는 데 부담을 느끼기도 했는데, 러닝쉐어 외에 다뤄볼 이야기들을 넓혔더니 러닝쉐어가 더 활발해지더라고요. 
특히 ‘이 주의 아젠다’ 코너를 시작한 것이 효과적이었어요. 이 코너는 UX리서치를 하면서 사소하더라도 은근 고민하게 되는 포인트를 가볍게 토론하기 위한 목적으로 시작했는데요. 토론하다 보면 다른 팀원의 고민에 조언을 주게 되기도 하고, 나의 업무방식을 되돌아보기도 하고, 기존 나의 방식에서 더 효율적인 방법을 찾게 되기도 하더라고요. 
나만의 고민이라고 생각했던 작은 고민에 대해 다른 리서처 팀원들의 공감 그리고 다양한 관점을 들어볼 수 있을 때 일하는 방식을 되돌아볼 수 있는 기회가 되는 것 같아요. ‘너무 소소한 주제면 어떡하지’ 하는 걱정도 필요 없어요. 팀원들이 소소한 아젠다더라도 늘 너무 진심으로 토론하는 바람에 항상 열띤 토론으로 마무리되거든요. 
‘이 주의 아젠다’로 다뤘던 주제들을 일부 소개해 드려요. 여러분은 아래 주제에 대해 어떤 생각을 가지고 계신가요? 한번 같이 일하는 팀원들과 이야기해 보세요. 
'컴포넌트가 클릭커블한지'를 검증 할 수 있을까?
인터뷰에서의 '중립성'은 어디까지 지켜야 할까?
사용자에게 ‘최근 경험’을 묻기 vs ‘평소 경험’을 묻기
‘재미’를 검증할 수 있을까?
아이스브레이킹과 인터뷰 안내를 위한 도입부 질문이 이어지는 인터뷰나 UT를 편향되게 할 수 있다면 어떻게 해야 할까?
토스 UX 리서처는 리서치의 처음부터 끝까지 혼자서 하나요?
토스의 UX 리서치 방법론에 대해서 시작해서 리서치팀의 위클리 러닝쉐어 문화를 소개했는데요. 제 이야기를 통해 이 질문에 대한 답변을 대신하고 싶어요.
리서처가 하나의 리서치 아젠다에 대해서 처음부터 끝까지 그 아젠다에 맞는 리서치 목표와 방법을 설정하고 이끌어 가는 것이 맞다고 생각하고 있어요. 하지만 리서치를 진행하며 드는 고민에 대해서는 찾아볼 수 있는 여러 사례와 식지 않는 토론방이 언제든 열려 있고 이 자리를 어떻게 활용하느냐에 따라 리서치 퀄리티를 얼마든지 높일 수 있어요. 
위와 같은 궁금함이 있으셨던 분들께는 리서치에 대한 책임과 권한은 오롯이 맡고 있지만 고민을 나눌 팀이 있기에, 리서치를 ‘혼자 하고 있다’는 생각은 해본 적 없다는 이야기를 드리고 싶어요. 
토스의 유저 리서치팀에 관심 있다면, 지금 지원하세요. 
UX 리서처 서류 프리패스 전형 (~3/24)

토스 UX 리서처는 어떤 방법론을 사용할까?

댓글