'이 기능 왜 안써?' 피그마와 쏘카의 A/B 테스트
코드스테이츠 PMB 17기 W5D3
이 기능.. 왜 안쓰세요?
내가 PM이라면 가장 많이 하게 될 질문일 것 같다. 분명 이 기능을 만들면 유저는 즐겁고 우리 회사는 돈을 벌고 모두가 행복할거야!라고 생각하지만, 유저는 호락호락하지 않다.
이런 가슴 아픈 상황에 PM은 어떻게 슬기롭게 문제를 해결할 수 있을까? 그리고 그 해결방안이 옳다는 것은 어떻게 알 수 있을까?
유니콘 기업인 '쏘카'와 유니콘을 넘어 데카콘에 등극한 'Figma' 조차도 이런 시행착오를 겪었기에, 그 사례를 통해 인사이트를 얻고자 한다.
+ 내가 해당 기업의 PM이 되었다고 가정하고 수행하고 싶은 A/B Test도 구상해보았다.
(아래의 내용은 피그마와 쏘카의 기술블로그에 기반해 작성했습니다.)
피그마의 '댓글 기능' A/B 테스트
실험 배경:
피그마는 웹 기반 디자인 툴로, 협업에 용이한 것이 특징이다.
실제로 피그마는 서비스 안에서의 협업 증대에 집중하고 있는데, 가입 후 첫 달에 피그마에서 협업을 하는 팀들은 그렇지 않은 팀들보다 1.75배의 retention을 기록하고, 6.5배 유료 결제로 전환한다는 데이터가 있기 때문이다. 그리고 피그마는, 이 협업에서 가장 중요한 기능을 에디터와 뷰어가 서로 피드백을 주고 받는 '댓글 기능'이라고 생각했다.
'뷰어'와 '에디터'란?
뷰어: 수정 권한 없이 파일을 확인하고 댓글을 달 수 있는 사람 (주로 디자이너 외 팀원)
에디터: 수정 권한까지 있는 사람 (주로 디자이너)
협업 증대의 중요성을 나타낸 데이터하지만 유저들이 생각보다 댓글 기능을 많이 사용하지 않았다. 디자인 과정에서 피드백을 주고 받는 것이 중요하고, 그 메인 툴은 분명히 '댓글'인데 왜 댓글 기능을 많이 사용하지 않을까? 피그마는 아래와 같이 문제를 정의했다.
문제 정의:
유저들이 댓글 기능의 존재를 인식하기 어렵다.
가설:
댓글 기능을 사용하도록 '안내'하면 댓글 생성율이 높아질 것이다.
개선 방법:
마우스 커서를 올려두면, 'Click anywhere to comment'라는 안내 메시지를 보여주며 댓글 기능이 있다는 것을 알린다.
(기존방식은, 왼쪽 상단의 코너에 아이콘을 선택해서 댓글을 작성할 수 있었다고만 나와있다. 아마 안내 메시지의 유무가 가장 큰 차이었던 것으로 보인다!)
하지만 이 개선 방법이 효과적일 것이라고 어떻게 장담할 수 있을까? A/B Test를 진행해보자.
개선 방안과 그 효과A/B Test:
2주간 대조군과 실험군을 50:50으로 나누어 기존방식과 개선 방식을 A/B test로 비교 (정확한 인원은 나와있지 않다.)
Test 타겟:
뷰어 권한으로 들어온 개발자들
타겟 선정 이유:
디자이너와 가장 긴밀하게 협업함에도 불구하고 가장 댓글기능을 사용하지 않고 있음.
결과:
개선안이 기존보다 댓글 생성이 45% 더 높았다. (성공!)
내가 피그마의 PM이라면 어떤 A/B 테스트를 해볼까?
피그마에서 정의한 문제는 '댓글 기능의 존재를 인지하기 어렵다'였다. 따라서 나라면, 뷰어 모드로 진입시 댓글 기능 옆에 'Leave a comment'라는 안내 메시지를 띄워볼 것 같다.
해당 '말풍선 아이콘'이 댓글 기능이라는 것도 명시할 수 있고, 유저가 댓글 아이콘을 가장 먼저 클릭해보도록 유도할 수 있을 것이다. 하지만 매번 안내 메시지를 띄우면 서비스의 사용성이 떨어질 것으로 예상되니, 대상은 신규 가입 유저로 한정하고자 한다.
가설: 아이콘 옆 안내 메시지를 설정하면 댓글 생성율이 높아질 것이다.
(기간 및 방식은 피그마가 진행했던 A/B Test와 동일하게 진행)
쏘카의 '부름 서비스' A/B Test
쏘카의 '부름 서비스'란(이하 '부름') 내가 지정한 위치로 차를 '부르는' 서비스이다. (쏘카존에 직접 방문해서 차를 픽업하고 그 자리에 차를 반납하는 '쏘카 왕복'(이하 '왕복)'과는 다르다.)
실험배경:
부름의 예약량 지표가 1년여간 정체되어 있었다. 분명 부름 서비스는 편리한데, 유저들은 왜 사용하지 않을까?
우선, 부름과 왕복은 엄연히 다른 서비스지만, 같은 예약 플로우를 공유하고 있었다. 지도를 열면 '쏘카존' pin과 '부름' pin이 둘다 생성되고(유저는 두 핀의 차이를 알기 어렵다), 심지어는 '쏘카존' pin을 선택한 후에도 부름 서비스를 예약할 수 있다.
왕복과 부름의 동일한 플로우당연히 '쏘카존' pin을 누른 후, 부름 서비스의 결제 페이지까지 전환되는 경우는 20%로 굉장히 낮았다. 애초에 목적이 부름 서비스가 아니라, 쏘카존을(왕복) 찾던 유저들이기 때문이다. 반대로 '부름' pin을 선택한 유저들의 결제 페이지까지의 전환율은 70%로 높았다. 이를 통해, '부름 차량을 빌려야지'라는 명확한 결심과 부름 서비스에 대한 이해가 전환의 중요한 요소라는 것을 알 수 있었다. 이를 토대로 쏘카는 아래와 같이 문제를 정의했다.
문제정의:
사용자는 앱에서 부름이 정확히 무슨 서비스이고, 무슨 장점이 있어서 예약해야 하는지 알기 힘들다.
부름을 한 번도 써보지 않은 상태에서는 차를 내가 지정한 장소로 부를 때 드는 걱정들이 어떻게 해결되는지, 쏘카가 어떤 방지책을 제공하는지 알기 힘들다.
한 번도 부름을 써보지 않은 사용자의 고통이 부름 이용 경험자 보다 크게 나타난다.
실제 쏘카의 유저인터뷰 결과가설:
지금처럼 왕복과 똑같은 Flow가 아닌, [부름 사용자] 관점에서 설계한 부름 전용 예약 Flow를 제공한다면, 결제 전환율의 차이와 기분 좋은 예약 경험 두 가지를 확인할 수 있을 것이다.
즉. 사용자에게 부름만의 매력을 직관적으로 전달하면서(=PMF 찾기) 불안감을 낮출 수 있는 예약 경험을 주어야 한다.
개선 방법: 부름 핀을 눌렀을 때, 왕복 핀을 눌렀을 때와 다른 '부름 전용' 신규 예약 페이지를 제작한다.
A/B Test (쏘카 블로그에서 정리를 너무 잘해두어, 그대로 가져왔다!)
실험 결과:
+ '부름과 왕복 서비스의 이용자는 서로 다른 니즈를 가졌다!'는 점에서 개선을 시작한 만큼, 지도에서 부름 pin을 선택하는 방법 외에도 메인 홈에 '여기로 부르기' 라는 부름만의 블록도 만들었다고 한다.
내가 쏘카의 PM이라면 어떤 A/B 테스트를 해볼까?
부름의 문제가 '정확히 무슨 서비스이고, 무슨 장점이 있어서 예약해야 하는지 알기 힘들다.'로 정의되었던 만큼, 어떤 서비스인지를 더 직관적으로 보여주는 UX Writing을 작성해 테스트 해보고 싶다. 부름의 서비스는 내가 현재 있는 '여기'로 부르는 것이 아니라 내가 '원하는 곳'으로 부르는 것에 더 가깝다고 생각한다. 이러한 부분을 확실하게 명시한다면, 최종 예약까지의 전환율이 높아질 것이라고 생각한다.
(앞서 언급했듯, '부름 차량을 빌려야지'라는 명확한 결심과 부름 서비스에 대한 이해가 전환의 중요한 요소라는 것이 증명되었기 때문!)
가설: '여기'가 아닌 '원하는 곳'으로 UX writing을 바꾸면, 예약 전환율이 높아질 것이다.
(기간 및 방식은 쏘카가 진행했던 A/B Test와 동일하게 진행)
인사이트
문제 정의의 중요성! 너무나도 체감했다. A/B Test를 해보려면 우선 무엇이 문제일지부터 정의해야 하는데, 뾰족하게 날을 세우지 않으면 인력만 낭비하는 Test가 되기 쉽다. 쏘카의 경우는 아예 새로운 예약페이지를 만드는 대공사였지만, 피그마는 작은 메시지 하나로 드라마틱한 효과를 냈다는 것이 특히 인상적이었다. 아마 무엇을 개선하려는지가 명백했기 때문일 것이다.
하지만 기죽을건 없다. 피그마의 A/B Test 실패 사례도 적혀있었는데, 댓글 기능을 메뉴 바의 왼쪽에서 오른쪽으로 옮기면 사용률이 높아질 것이라는 가설을 세웠지만, 실험 결과 오히려 반대였다고 한다. 이처럼 대부분의 가설은 틀리다! 그렇기 때문에 직관이 아닌 A/B Test가 필요하고, 꾸준한 검증이 필요하다.
