A/B테스트하는데 디자인도 이것저것 다 바꾸고 싶어요
Editor : 김은총 (Product Designer)
제품 스쿼드는 항상 어제보다 더 나은 제품을 만들기 위해 노력합니다. 빠른 속도로 문제와 가설을 구체화하고 이를 위한 실험을 반복하죠.
하지만 이 삶의 현장을 가까이서 들여다보면 모든 일이 정론처럼 흘러가지는 않습니다. 가령 가설을 검증하는 과정에서 UI적인 레거시를 걷어내거나, 실험하고자 하는 내용은 아니지만 전환율 상승을 위해 버튼의 위계를 높이는 등 실험 외적인 변수가 등장하곤 합니다.
정확한 실험을 통해 명징한 러닝을 얻는 것과, 직관으로 빠르게 비즈니스 성과를 일궈내는 것 사이 의사결정은 스쿼드 안에서 합의가 필요한 일입니다. 정답은 없다는 가정 아래, 알다의 대출비교를 담당하는 론스쿼드에선 어떤 식으로 커뮤니케이션이 진행되었을까요?
이터레이션 돌리기는 너무 어려워
커다란 프로젝트를 쪼개서 속도감 있게 개선하는 이터레이션은 이미 많은 메이커들이 알고 있는 과정입니다. 그리고 이상적인 이터레이션의 형태를 그림으로 풀면 아래와 같은 모습이 나옵니다.
하지만 우리는 정말 이렇게 일하고 있을까요?
사이즈를 쟀을 때 더 맛깔난 백로그가 있다면 당연히 우선순위는 바뀌게 됩니다. 여기에 제휴사와 관계를 이어나가야 하는 대출비교 플랫폼의 특성상 비즈니스적 애드혹이 빈번하게 들어오는 편이에요. 그래서 현실적으로는 이런 그림이 나오게 됩니다.
여기서 비즈 요청이 더 자주 들어오면 어떻게 될까요? 획기적이다 싶은 새 아이템이 등장하면? 우리가 익히 알던 이터레이션 형태와는 점점 더 멀어지고 뇌리에는 한 문장의 생각이 점차 지배적으로 들기 시작합니다.
지금 하는 개선 아이템이 다시는 돌아오지 않을 수도 있다
프로덕트 디자이너인 저 개인적으로는 ‘지금 이 화면을 개발하기로 했을 때 쇠뿔도 단김에 빼자’는 생각을 자주 하는 편입니다. 디자인적으로 레거시인 컴포넌트를 갈아치우면서 문제를 해결할 수 있는 가설도 함께 녹였으면 하는 다소 억척스러운 바람이죠. 그도 그럴 게 비즈니스 가치를 따지다 보면 특정 디자인 백로그는 반평생 액션아이템 반열에 올라오지 못하는 상황도 흔하니까요.
하지만 데이터 애널리스트의 생각은 다를 수 있습니다. 하단의 버튼도, 상단의 문구도 전부 바뀌면 정작 무엇이 변인인지 알기 어려워지죠. 실험을 통해 러닝을 얻어야 하는데 실험의 의미 자체가 퇴색될 수도 있었습니다.
론스쿼드에서 실험 중인 아이템을 예로 들어보겠습니다. 우리는 대출 상품을 추천하는 페이지에서 ① Head 섹션과 ② 버튼 컴포넌트 총 2가지 요소를 변경했어요.
섹션 ①은 우리가 실험하고자 했던 가설이 담긴 부분입니다. 신뢰할 수 있는 구체적인 숫자를 문구에 삽입했을 때 전환에 얼마나 영향을 주는지를 확인하고자 했어요.
섹션 ②는 디자인 개선이었습니다. CTA 버튼과 대출상품을 묶어 하나의 덩어리로 보이도록 연관성을 높였습니다. 완벽한 효율 검증을 위해서는 이 또한 테스트를 진행해야 했지만 ‘직관적으로’ 전환율이 개선되리라 기대하는 부분이었죠.
섹션 ②의 변화가 작지 않기 때문에 대조군 A와 실험군 B의 실험 외적인 차이가 생겨 가설이 명확히 검증되지 않을 수 있다는 것이 문제였어요. 그리고 긴 논의 끝에 우리가 내린 결론은 다음과 같았습니다: “섹션 ②의 변화는 디벨롭으로 판단, 현재 운영 중인 A안에도 반영해 A / B / C 모두 동일한 환경으로 실험을 진행하자.”
그리고 해당 내용은 회고 시간의 뜨거운 감자(?)가 되었습니다. 앞으로도 계속 발생할 수 있는 이슈임은 분명한데, 그때마다 매번 게릴라로 논의하며 소모될 리소스를 생각해서라도 어느 정도 핏을 맞추고 갈 필요가 있다고 생각했어요.
우리는 A/B테스트를 왜 할까요?
A/B테스트는 왜 하는 걸까요? 기본적으로 A/B테스트의 취지는 실험안의 변수가 유의미한 변화를 도출해내는지를 확인하기 위함입니다. 때문에 변수가 많아질수록 어떤 변수가 변화의 원인이었는지를 알기 어렵고 복잡해지는 것이 사실입니다.
그렇다면 ‘우리는’ 왜 A/B테스트를 하는 걸까요? A/B테스트의 의의 그 이상으로 우리가 회사에서 A/B테스트를 이어가는 이유는 결국 빠른 실험 → 러닝 → 그리고 더 빠른 개선을 통해 스쿼드 전체가 속도감 있게 달리는 것이 가능해지기 때문일 겁니다.
직관이 있더라도 A/B테스트는 할 수 있다면 하는 게 맞습니다. 하지만 스쿼드의 속도를 위해 진행하는 실험이 도리어 속도를 늦추는 현상은 분명 아이러니합니다. 관련해서 회고를 옵저빙하던 Head of Product 지혜님도 몇 가지 의견을 주셨어요.
- 스쿼드를 더 빠르게 굴리기 위해 A/B를 하는 건데, A/B를 명확히 하기 위해 개발이 느려지는 건 순서가 반대 같다.
- PD가 설계한 화면에서 변수가 여러 개일 때 명확한 러닝은 얻을 수 없지만, 전보다 이 화면이 나아졌다는 사실은 알 수 있다.
제안은 있어도 정답은 없다
결론적으로 우리는 A/B테스트에서 변수가 1개인 것이 ‘정답에 가깝다’는 관념에서 벗어나기로 했습니다.
물론 개선을 측정할 수 있는 액션아이템으로서 결론이 매듭지어진 것은 아닙니다. 그러나 분명히 개개인의 전문성 이상으로 스쿼드적 합의와 유연함에 대해 생각할 수 있는 프로젝트였으며, DA와 PD가 더 긴밀하게 협업할 수 있는 포인트 하나를 더 발굴해내 기꺼운 마음 또한 전달할 수 있었다는 러닝쉐어를 공유합니다.
우리가 이미 알고 있는 이슈가 재발했을 때, 한번이라도 스쿼드 안에서 합의점을 찾으려고 노력했던 이슈와 그렇지 않은 이슈 사이의 커뮤니케이션 비용은 생각보다 더 큰 차이가 발생합니다.
PD는 디자인을 진행하기 전 한번 더 DA와 점검하면서 문제점을 보완할 수 있고, DA는 현재의 실험 이상으로 스쿼드, 그리고 회사가 빠르게 움직일 수 있는 커다란 환경을 보는 시각을 고려할 수 있게 되었습니다.
이렇듯 알다에서는 제품만큼이나 스쿼드 또한 계속해서 실험하고 실패하며 개선을 이어나가고 있습니다. 앞으로도 더 빠르고 선명하게 성장해나갈 알다를 계속해서 지켜봐주세요!
