<div id="readability-page-1" class="page"><div>안녕하세요. 저는 토스 팀원들이 <a target="_blank" rel="noreferrer noopener" href="https://toss.tech/article/what-is-research-ops">더 쉽고, 효율적으로 유저 리서치를 할 수 있는 환경을 만드는 일</a>을 하고 있어요.<a target="_blank" rel="noreferrer noopener" href="https://toss.tech/article/ux-research-platform">유저 무물데이</a>를 어떤 분들이 어떻게 활용하고 있는지 살펴보니, PD (Product Designer)분들이 제품 출시 전, 프로토타입 테스트 용도로만 주로 활용하고 있는 것을 발견했어요.프로토타입 테스트뿐 아니라 제품 배포 후 실제 앱에서 사용자들이 어떻게 쓰는지 보는 것 또한 프로토타입 테스트만큼 중요한데, 라이브 환경에서 사용성 테스트 (UT)는 많이 하고 있지 않다는 것을 데이터로 확인했어요.그래서 몇몇 PD분들을 만나 그 이유를 여쭤봤어요. 제품 배포 후에는 데이터가 쌓이니 지표나 다양한 채널로 들어오는 cs나 voc를 통해 문제를 파악하거나 A/B 테스트로 검증할 수 있어 굳이 리소스를 들여 사용자를 만나 정성조사를 할 필요를 못 느끼는 분들도 있었고, 라이브 UT에서 문제가 나와도 당장 사일로에서는 매출, 유저 수, 리텐션 등 지표와 관련 있는 다음 실험을 준비하기 때문에 우선순위에 밀려 제품 개선이 이루어지기 쉽지 않다고 이야기해 주시는 분들도 있었어요. PD분들은 사용성에 문제가 있다는 것을 인지하고 있더라도, 제품은 팀원들 다 같이 만들다 보니 제품을 변경하려면 공감대 형성이 필수적이었는데 혼자서는 라이브 UT를 진행하는 것부터 진행 후 문제 개선을 설득하기 쉽지 않았던 것이죠. <h3 id="14ba360d-33e3-80a1-9f0c-edf3b03d7082">사용성 문제. 중요한 건 알지만..</h3>각 팀에서는 매출, 전환율 등 팀의 목표 달성이 중요하다 보니, 전체 제품의 정성적 사용성에 대해서는 우선순위가 밀릴 수밖에 없었어요. 이 문제를 중요하게 생각하는 팀원이 있다고 해도, 나머지 팀원들과 공감대를 형성하려면 논의가 길어져서 시간이 오래 걸리는 문제도 있었죠. 사용성을 중요하게 생각하는 프로덕트 디자이너는 어떤 디자인이 사용성이 좋고, 좋지 않은지 알고 있지만 다른 팀원들은 사용자의 경험을 직접 본 적이 없기 때문에 공감하기 어려워하는 상황이 발생했어요.그래서 PD 분들뿐만 아니라 사일로 구성원 모두 비슷한 유저 감수성을 갖는 것이 중요하겠다 생각했어요. 우리는 토스 앱을 매일 보니 너무나 쉽고 당연하게 이용하는 것도, 유저는 못 보고 지나치거나, 이해하지 못하고, 이용하기 어려워한다는 것을 말로 설명하는 것보다 직접 보여 드려야겠다고 생각했죠.게다가 PD, PO (Product Owner), PM(Product Manager), 이 외의 개발자, DA(Data Analyst) 등 다른 직군들은 열심히 제품은 만들고 계시지만, 실제로 유저가 어떻게 쓰는지 볼 기회가 없었어요. 이러한 기회를 만들어 주는 것이 필요하겠다고 생각했어요.<h3 id="14ba360d-33e3-80f1-8f39-f9b45faf2d45">어떻게 중요성을 효과적으로 알릴 수 있을까?</h3>사일로 팀원들이 뚜렷한 목적이나 준비를 하지 않더라도 사용자 인터뷰에 참여해 생생한 유저의 목소리를 듣는다면, 유저에 대한 공감대가 높아지고 유저 리서치의 중요성과 필요성을 체감할 것이라고 생각했어요.유저의 생생한 목소리를 듣도록 하려면, 듣는 것 이 외의 모든 준비 과정이나 허들을 없애야 한다고 생각했어요. 그리고 실제로 아무 준비 없이 몸만 와도 괜찮다고 공지를 하고 실제로 팀원들도 그렇게 느낄 정도로 물리적, 심리적 허들을 낮추는데 집중했어요.첫 번째로 고려했던 것은 시간이에요. 다들 미팅, 본업 등으로 바쁘시다 보니 1시간 동안 시간을 내라고 하면 부담스러워할 것 같았어요. 그래도 사일로 구성원들끼리 보통 점심을 같이 먹기 때문에, 따로 시간을 내거나 약속할 필요 없는 점심시간으로 시간을 설정했어요.두 번째로는 모든 준비를 다 해주고 몸만 오도록 하는 것이었어요. 시간은 맞췄는데, 프로그램 신청과 참여를 위해 준비를 많이 해 오도록 하면 부담을 느끼실 것 같았어요. 그래서 유저에게 궁금한 것만 말씀해 주시면, 사용자 리크루팅부터 질문지 설계, 인터뷰 진행까지 모두 다 대신해 드렸어요. 심지어 점심 메뉴 세팅까지 대신해 드렸니, 얼마나 가볍게 오면 되는지 아시겠죠?세 번째로는 인터뷰 주제였어요. 프로그램을 통해 주고자 했던 밸류를 사일로 구성원들 모두 얻어 갈 수 있도록 하기 위해서 제일 신경을 썼던 부분인데요. 직군과 상관없이 모두 관심을 가질 수 있어야 하기 때문에, 인터뷰 주제와 질문지 구성이 중요했어요. 점심시간으로 프로그램이 짧다 보니 많은 유저를 만날 수 없었고, 인터뷰 시간도 길게 잡을 수 없었어요. 그리고 단순히 유저의 경험을 듣는 것보다는 본인들이 개발한 화면이 유저의 휴대폰에서 어떻게 구현되는지 직접 보는 것이 개발자분들에게 더 신선할 것 같았어요. (간혹 숨어있는 버그도 덤으로 찾아갈 수 있고요!)그래서 20분씩 2명의 다른 세그먼트의 유저를 만나 평소 제품 사용 경험을 토스 앱을 보며 질문했어요.<code>10분</code>처음 10분은 팀원들과 인사를 나누고 프로그램에 대해 소개해요.<code>20분 X 2명</code>그리고 20분씩 2번의 유저 인터뷰를 진행했어요. 이때 팀원들이 질문을 슬랙에 남겨주면 바로 질문해 되도록 궁금한 점을 해소해 주기 위해 노력했어요.PD, PO 뿐만 아니라 데이터 직군, 개발자도 활발하게 궁금한 것들을 질문해 주셨어요.<figure id="14ba360d-33e3-80e3-b984-c91d645e5aff"><img src="https://static.toss.im/ipd-tcs/toss_core/live/afd6f4da-9cea-493d-b41e-9bba4897fa04/img-techblog-inner-1126-1.png" alt=""><figcaption>10월 22일 진행한 사일로 스레드 내용</figcaption></figure><code>10분</code>마지막 10분은 인터뷰 내용 중 어떤 부분이 인상적이었는지 등 간단히 후기를 질문하고 마무리했어요. 그리고 유저 리서치가 무엇이고, 어떻게 활용하는 것인지 모르는 분들도 계시기 때문에 단 2명의 유저를 만나는 것이고, 이 2분이 우리 제품을 쓰는 모든 유저로 일반화하지 않도록 같이 말씀드렸어요.프로그램이 종료했는데도, 사일로 팀원들끼리 치열하게 앞으로 제품 방향성에 대해 남아서 이야기하는 모습을 볼 수 있었어요.<h3 id="14ba360d-33e3-80d8-bef0-fdbfa4c2be9e">프로그램 참여 이후</h3>참가한 대부분의 팀원들이 캐주얼하고 부담 없이 유저의 목소리를 들을 수 있어 좋았고, 우리에게 당연한 것이 유저에게 당연한 것이 아니라는 것을 보게 되어 유익했다고 공통적으로 이야기해 주셨어요. 이런 후기를 유저를 접할 기회가 없었던 DA, 개발자 등 직군 상관없이 모두 해 주신 이야기라 더욱 뜻깊어요.<figure id="14ba360d-33e3-80ec-9c27-e83e290dc901"><img src="https://static.toss.im/ipd-tcs/toss_core/live/0f1681c0-f073-4f22-bfa8-2b0ea5e23b5d/img-techblog-inner-1126-3_(1).png" alt=""></figure><figure id="14ba360d-33e3-80d5-8d1c-e8059d70fa52"><img src="https://static.toss.im/ipd-tcs/toss_core/live/ac33396c-ab43-4325-b4e2-a79dd872ba11/img-techblog-inner-1126-4.png" alt=""></figure>물론 크고 작은 사용성 문제가 나왔는데요. 따로 고쳐달라고 요청드리지 않았는데도, 현재 사일로 지표와 무관한 문제를 개발자분께서 따로 챙기고 계셨어요.<figure id="14ba360d-33e3-8059-9b03-da6b22b724f3"><img src="https://static.toss.im/ipd-tcs/toss_core/live/8ec6dd76-590b-4571-b010-d6ced6a03c69/img-techblog-inner-1126-2.png" alt=""></figure>어떻게 제품을 만드는지가 유저가 제품을 어떻게 쓰는지에 영향을 미치는 것을 직접 보게 되었고 더욱 제품에 대해 주인 의식을 갖고 고객 관점에서 고민할 수 있는 계기를 마련한 것 같아요. 프로세스를 단축하거나 리서치 도구를 새롭게 만드는 것뿐만 아니라 팀원들끼리 비슷한 공감대를 형성하는 것과 리서치를 더 부담 없이 하도록 환경을 마련하는 것 또한 효율화의 일환이라고 생각해요.<h3 id="14ba360d-33e3-80e1-87a9-d01f37d919eb">적용해보기</h3>사용성 문제. 팀원들을 설득하기 어렵나요? 유저 리서치 보다 데이터로, 실험으로 충분하다고 생각하는 분위기인가요? 그렇다면 다 같이 유저 인터뷰를 해 보세요.우리 제품을 이용하는 유저는 정말 다양해요. 데이터로 보지 못 한 유저의 맥락을 지레짐작하기보다는 유저를 직접 만나 물어보세요. 그리고 단순히 인터뷰 결과를 정리해 팀원들과 공유하기보다는 시간이 괜찮다면 팀원들과 함께해 보세요. 팀원들과 제품을 바라보는 시각을 맞추고 논의를 훨씬 효율적으로 만들어줄 거예요.</div></div>

토스테크

안녕하세요. 저는 토스 팀원들이 더 쉽고, 효율적으로 유저 리서치를 할 수 있는 환경을 만드는 일을 하고 있어요.
유저 무물데이를 어떤 분들이 어떻게 활용하고 있는지 살펴보니, PD (Product Designer)분들이 제품 출시 전, 프로토타입 테스트 용도로만 주로 활용하고 있는 것을 발견했어요.
프로토타입 테스트뿐 아니라 제품 배포 후 실제 앱에서 사용자들이 어떻게 쓰는지 보는 것 또한 프로토타입 테스트만큼 중요한데, 라이브 환경에서 사용성 테스트 (UT)는 많이 하고 있지 않다는 것을 데이터로 확인했어요.
그래서 몇몇 PD분들을 만나 그 이유를 여쭤봤어요. 제품 배포 후에는 데이터가 쌓이니 지표나 다양한 채널로 들어오는 cs나 voc를 통해 문제를 파악하거나 A/B 테스트로 검증할 수 있어 굳이 리소스를 들여 사용자를 만나 정성조사를 할 필요를 못 느끼는 분들도 있었고, 라이브 UT에서 문제가 나와도 당장 사일로에서는 매출, 유저 수, 리텐션 등 지표와 관련 있는 다음 실험을 준비하기 때문에 우선순위에 밀려 제품 개선이 이루어지기 쉽지 않다고 이야기해 주시는 분들도 있었어요. 
PD분들은 사용성에 문제가 있다는 것을 인지하고 있더라도, 제품은 팀원들 다 같이 만들다 보니 제품을 변경하려면 공감대 형성이 필수적이었는데 혼자서는 라이브 UT를 진행하는 것부터 진행 후 문제 개선을 설득하기 쉽지 않았던 것이죠. 
사용성 문제. 중요한 건 알지만..
각 팀에서는 매출, 전환율 등 팀의 목표 달성이 중요하다 보니, 전체 제품의 정성적 사용성에 대해서는 우선순위가 밀릴 수밖에 없었어요. 이 문제를 중요하게 생각하는 팀원이 있다고 해도, 나머지 팀원들과 공감대를 형성하려면 논의가 길어져서 시간이 오래 걸리는 문제도 있었죠. 사용성을 중요하게 생각하는 프로덕트 디자이너는 어떤 디자인이 사용성이 좋고, 좋지 않은지 알고 있지만 다른 팀원들은 사용자의 경험을 직접 본 적이 없기 때문에 공감하기 어려워하는 상황이 발생했어요.
그래서 PD 분들뿐만 아니라 사일로 구성원 모두 비슷한 유저 감수성을 갖는 것이 중요하겠다 생각했어요. 우리는 토스 앱을 매일 보니 너무나 쉽고 당연하게 이용하는 것도, 유저는 못 보고 지나치거나, 이해하지 못하고, 이용하기 어려워한다는 것을 말로 설명하는 것보다 직접 보여 드려야겠다고 생각했죠.
게다가 PD, PO (Product Owner), PM(Product Manager), 이 외의 개발자, DA(Data Analyst) 등 다른 직군들은 열심히 제품은 만들고 계시지만, 실제로 유저가 어떻게 쓰는지 볼 기회가 없었어요. 이러한 기회를 만들어 주는 것이 필요하겠다고 생각했어요.
어떻게 중요성을 효과적으로 알릴 수 있을까?
사일로 팀원들이 뚜렷한 목적이나 준비를 하지 않더라도 사용자 인터뷰에 참여해 생생한 유저의 목소리를 듣는다면, 유저에 대한 공감대가 높아지고 유저 리서치의 중요성과 필요성을 체감할 것이라고 생각했어요.
유저의 생생한 목소리를 듣도록 하려면, 듣는 것 이 외의 모든 준비 과정이나 허들을 없애야 한다고 생각했어요. 그리고 실제로 아무 준비 없이 몸만 와도 괜찮다고 공지를 하고 실제로 팀원들도 그렇게 느낄 정도로 물리적, 심리적 허들을 낮추는데 집중했어요.
첫 번째로 고려했던 것은 시간이에요. 다들 미팅, 본업 등으로 바쁘시다 보니 1시간 동안 시간을 내라고 하면 부담스러워할 것 같았어요. 그래도 사일로 구성원들끼리 보통 점심을 같이 먹기 때문에, 따로 시간을 내거나 약속할 필요 없는 점심시간으로 시간을 설정했어요.
두 번째로는 모든 준비를 다 해주고 몸만 오도록 하는 것이었어요. 시간은 맞췄는데, 프로그램 신청과 참여를 위해 준비를 많이 해 오도록 하면 부담을 느끼실 것 같았어요. 그래서 유저에게 궁금한 것만 말씀해 주시면, 사용자 리크루팅부터 질문지 설계, 인터뷰 진행까지 모두 다 대신해 드렸어요. 심지어 점심 메뉴 세팅까지 대신해 드렸니, 얼마나 가볍게 오면 되는지 아시겠죠?
세 번째로는 인터뷰 주제였어요. 프로그램을 통해 주고자 했던 밸류를 사일로 구성원들 모두 얻어 갈 수 있도록 하기 위해서 제일 신경을 썼던 부분인데요. 직군과 상관없이 모두 관심을 가질 수 있어야 하기 때문에, 인터뷰 주제와 질문지 구성이 중요했어요. 점심시간으로 프로그램이 짧다 보니 많은 유저를 만날 수 없었고, 인터뷰 시간도 길게 잡을 수 없었어요. 그리고 단순히 유저의 경험을 듣는 것보다는 본인들이 개발한 화면이 유저의 휴대폰에서 어떻게 구현되는지 직접 보는 것이 개발자분들에게 더 신선할 것 같았어요. (간혹 숨어있는 버그도 덤으로 찾아갈 수 있고요!)
그래서 20분씩 2명의 다른 세그먼트의 유저를 만나 평소 제품 사용 경험을 토스 앱을 보며 질문했어요.
10분
처음 10분은 팀원들과 인사를 나누고 프로그램에 대해 소개해요.
20분 X 2명
그리고 20분씩 2번의 유저 인터뷰를 진행했어요. 이때 팀원들이 질문을 슬랙에 남겨주면 바로 질문해 되도록 궁금한 점을 해소해 주기 위해 노력했어요.
PD, PO 뿐만 아니라 데이터 직군, 개발자도 활발하게 궁금한 것들을 질문해 주셨어요.
10분
마지막 10분은 인터뷰 내용 중 어떤 부분이 인상적이었는지 등 간단히 후기를 질문하고 마무리했어요. 
그리고 유저 리서치가 무엇이고, 어떻게 활용하는 것인지 모르는 분들도 계시기 때문에 단 2명의 유저를 만나는 것이고, 이 2분이 우리 제품을 쓰는 모든 유저로 일반화하지 않도록 같이 말씀드렸어요.
프로그램이 종료했는데도, 사일로 팀원들끼리 치열하게 앞으로 제품 방향성에 대해 남아서 이야기하는 모습을 볼 수 있었어요.
 
프로그램 참여 이후
참가한 대부분의 팀원들이 캐주얼하고 부담 없이 유저의 목소리를 들을 수 있어 좋았고, 우리에게 당연한 것이 유저에게 당연한 것이 아니라는 것을 보게 되어 유익했다고 공통적으로 이야기해 주셨어요. 이런 후기를 유저를 접할 기회가 없었던 DA, 개발자 등 직군 상관없이 모두 해 주신 이야기라 더욱 뜻깊어요.
물론 크고 작은 사용성 문제가 나왔는데요. 따로 고쳐달라고 요청드리지 않았는데도, 현재 사일로 지표와 무관한 문제를 개발자분께서 따로 챙기고 계셨어요.
어떻게 제품을 만드는지가 유저가 제품을 어떻게 쓰는지에 영향을 미치는 것을 직접 보게 되었고 더욱 제품에 대해 주인 의식을 갖고 고객 관점에서 고민할 수 있는 계기를 마련한 것 같아요. 프로세스를 단축하거나 리서치 도구를 새롭게 만드는 것뿐만 아니라 팀원들끼리 비슷한 공감대를 형성하는 것과 리서치를 더 부담 없이 하도록 환경을 마련하는 것 또한 효율화의 일환이라고 생각해요.
적용해보기
사용성 문제. 팀원들을 설득하기 어렵나요? 유저 리서치 보다 데이터로, 실험으로 충분하다고 생각하는 분위기인가요? 그렇다면 다 같이 유저 인터뷰를 해 보세요.
우리 제품을 이용하는 유저는 정말 다양해요. 데이터로 보지 못 한 유저의 맥락을 지레짐작하기보다는 유저를 직접 만나 물어보세요. 그리고 단순히 인터뷰 결과를 정리해 팀원들과 공유하기보다는 시간이 괜찮다면 팀원들과 함께해 보세요. 팀원들과 제품을 바라보는 시각을 맞추고 논의를 훨씬 효율적으로 만들어줄 거예요.

토스 팀은 점심 시간에 사용자를 만난다

댓글