brunch

라이킷 35 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by ezy Dec 14. 2018

디자이너의 AB테스트

실패는 성공의 어머니래요

근 1-2년 사이 데이터 기반 디자인이 유행처럼 번졌다. 열정 넘치는 스타트업의 신입 디자이너는 "나도 데이터를 볼 줄 아는 디자이너가 될 거야”라는 포부를 가지고 있었더랬다.

이 경험담은 BM은 커녕, 방향성도 잘 모르는 극초기 스타트업에 속한 주니어 디자이너의 AB테스트 회고록이다. 나와 같은 상황의 디자이너가 이 글을 통해 당신만 삽질하는 것이 아니라는 심심한 위로를 받을 수 있기를 바란다.

바빠 죽겠는데, 왜 하려 하는 건데?

입사 이래 나에게 가장 어려운 과제는 제품 메인화면 기획이었다. 보통 어느 서비스든 메인화면을 보면, 그 회사의 정체성과 나아가고자 하는 방향을 알 수 있다. 우리 제품은 유사한 서비스나 경쟁사가 없기 때문에, 메인화면을 어떻게 구성하느냐에 따라 제품 분야나 시장이 완전히 달라질 수 있었다.

내가 확신이 없으니, 그것이 곧 설득의 어려움이다. 본래 나는 이성적이고 논리적인 성향에 가깝다. 스스로 기준점이 서지 않고 근거가 확실치 않으면, 애초에 시작을 못한다. 나 자신이 설득되지 않는데, 어떻게 팀원들을 설득하고 제품을 만들며, 사용자에게 다가갈 수 있을까. 이런 상황에서 AB테스트는 내 찝찝함을 해소해줄, 뭔가 객관적인 근거를 만들어 줄 것만 같은 구세주였다.

그냥. 남들이 하길래. 그런 이유로 시작하기에는 스타트업은 너무 바쁘다. 먼저 디자이너로서 왜 AB테스트가 하고 싶은지, AB테스트가 최선의 방법일지 생각해보자. 사실 작은 규모일수록 작은 스펙으로 먼저 하나를 내놓고, 시장의 반응에 따라 조금씩 바꿔나가는 것이 AB테스트보다 더 빠를 수 있다.

작고 빠르게

기획은 거창하지 않아도 된다. 나의 경우 테스트 진행 목적, 목표, 가설 중심으로 개요를 작성했다. 일반적인 제품 KPI인 전환율/클릭률/체류 시간 이 3가지 안에서 결정했다. 가장 중요한 것은 가설이다. 가설은 곧 디자이너의 사고 과정을 보여준다. 내가 해결하고자 하는 문제의 해결 방안, 디자인 솔루션을 내포하고 있다.

내가 세운 가설은 다음과 같다.

사용자의 일정 확인을 중심으로 한 A안 대비, 콘텐츠를 강조한 디자인의 B안이 엔드 페이지로의 전환율이 더 높을 것이다.

콘텐츠를 강조한 피드 형식의 B안이 더 높은 체류시간을 가질 것이다.

공유 버튼을 메인에 노출한 B안이 더 높은 클릭률을 보일 것이다.

욕심쟁이다. 첫 테스트에, 한 번에 3가지의 결과를 얻고자 했다. A안과 B안은 전혀 다른 UI를 띄고 있었고, 그 두 가지 화면을 모두 디자인하고 모두 개발해야 했다. 속도가 중요한 스타트업에서는 효율성이 떨어질뿐더러, 큰 UI의 변화는 사이드 이펙트를 불러올 수 있다. 욕심내지 말자. 첫 술에 배부를 수 없다. 적은 노력으로 작은 인사이트를 얻을 수 있게끔 설계해야 한다.

조력자와의 커뮤니케이션

기획안을 들고 날 도와줄 마케터와 개발자를 찾아간다. 이 테스트가 우리의 제품에 궁극적으로 어떤 영향을 미칠지, 디자인 프로세스에 어떤 도움을 줄 수 있을지 적극적으로 어필한다. 궁금한 점도 많이, 디테일하게 정리해간다. 에이 설마 이건 되겠지 하는 것도 물어보자.

이 과정에서 다소 수학적인 사고방식(=머리가 터지는)을 요할 수도 있는데, 그들을 귀찮게 해서라도 꼭 이해하고 넘어가고 잘 정리해두어야 한다. 애매하게 이해하면, 나중에 결과가 나왔을 때 내가 의도한 바대로 진행되지 않았음을 깨닫는다. 댓츠 투 레이트..

사실 디자이너라면 그냥 이거랑요 이거 비교해서 결과 알려주세요.라고 말할 수 있겠다. 그러나 한번 이런 과정을 겪으면, 다음에 좀 더 수월하게 기획할 수 있을뿐더러 조력자에게 좀 더 당당하게 요구할 수 있다.

제품의 상태 파악하기

우리 제품이 내가 얻고자 하는 데이터를 얻을 수 없는 환경에 처해있을 수도 있다. 만약 테스트 시작 시점을 기준으로 이전에 쌓아온 데이터와 비교하고자 한다면, 이전 데이터가 아예 없을 수 있다. (롸?) 우리 팀 역시 계획은 무슨, 배포할 때마다 필요하다고 생각 드는 대로 코드를 심어두었기 때문에..

이런 경우 특정 데이터가 쌓이기 시작한 시점이 언제인지를 명확히 알고 있는 것이 중요했다. 또한 얻고자 하는 데이터가 현재 팀 내에서 사용 중인 툴로 파악하기 어려울 수 있다. 먼저 제품의 데이터 현황과 툴에 대해 충분한 리서치 및 의논을 하도록 한다.

디자인에 반영하기

본격적인 디자인을 하는 과정에서는, '내가 설정한 가설을 최대한 반영하여 디자인하고 있는가?'를 스스로에게 끊임없이 되물어야 한다. 물론 내가 가설을 세웠기 때문에 의도가 반영될 것이다. 그러나 유저의 행동에 여러 가지 요소가 영향을 미치기 때문에, 주요 컴포넌트는 물론 화면 단위에서 이 테스트에 변수가 될만한 요소가 없는지 주의한다. 디자인적 요소뿐 아니라 마케팅, 콘텐츠적 사항들도 포함된다. 변수가 될만한 요소들을 미리 리스트로 만들어두면, 후에 결과를 분석할 때 고려할 수 있다.

분석 과정 짚어보기

데이터가 나오면 다 해결될 줄 알았지? 응. 정말 그렇게 생각했어요. 이거랑 저거랑 뽑아서 계산하면 뿅! 비율은 상대적이기 때문에 누가, 어떻게 분석하느냐에 따라 결과도 달라진다. 마케터가, 개발자가 주는 숫자를 그대로 받는 것도 좋지만 그들이 어떤 데이터를 모수로 잡고, 어떤 비교 과정을 통해 결과를 냈는지 흐름을 따라가 보도록 한다. 나의 목적이 반영되었는지, 발견하지 못한 변수나 실수가 있지는 않았는지 의구심을 줄일 수 있다.

결국은 나의 몫

숫자 분석은 내가 하지 않지만, 인사이트를 도출하고 판단하여 활용하는 것은 디자이너의 몫이다. 데이터는 무엇이 더 높고 낮은지 말해주지만 그 이유를 말해주지는 않는다. 이를 해소하기 위해 추가적인 유저 테스트를 진행했다. 유저 인터뷰나 서베이를 통해 각각이 선택한 UI에 대해 어떻게 느끼는지, 왜 그런 행동을 하게 되었는지 파악하려 했다.

유저 인터뷰와 AB테스트 모두 유저의 눈 앞에 두 가지 결과물만을 제공하여 진행하는 것이다.

결국 유저의 의견은, 제품 개발 시 고려되는 -회사의 비즈니스와 목표, 내/외부 이해관계자, 제품의 정체성 등- 과 같은 수많은 잣대들 중 하나다.

결국 판단은 나의 몫이다.

요약하면 다음과 같다

1. AB테스트에 당위성 부여하기

2. 우리 규모에 과한 욕심을 부리는 스펙은 아닌가?

3. 조력자 괴롭히기

4. "일단 테스트가 가능한가요?"

5. 내 멋대로 디자인하고 있진 않은가?

6. 조력자 괴롭히기 2

7. 선택은 결국 내가 하는 것

keyword