뾰족한 가설로 필요한 일만 잘하기
등잔 밑이 어둡다더니, 당연한 문제도 다시 보자!
A 서비스의 목표 지표는 "서비스 신청 완료 건수"였다.
하지만 지표는 좀처럼 우상향 하지 않았고, 원인은 1~5단계로 이루어진 플로우 중 2, 3단계에서의 이탈이 꼽혔다. 그러자 슬슬 문제 단계의 UI/UX 화면이 개선되어야 하는 게 아니냐는 말이 들리기 시작했다. 기획자라면 익숙한 상황일 것이다. 나도 처음엔 고민했다. 그렇게 "UI가 복잡한 걸까?" "문구가 어렵나?"로 시작했던 고민은 점점 더 복잡해졌고, 시간만 지체될 뿐이었다.
그러다 문득, “그 단계가 정말 필요한 건가?"라는 생각이 들었고, '사용자는 왜 이 단계에서 멈추는가'보다 더 앞서, '이 단계를 정말 지나야 만 하는가'를 고민하기 시작했다. 이번 글에서는 이렇게 시작했던 우리의 작은 실험 과정을 적어본다!
✅ 문제를 다시 들여다보기
A 서비스의 주요 플로우는 아래와 같았다.
메인 화면 진입 → 신청자 정보 확인 → 알림 수단 선택 → 서비스 이용 동의 → 신청 완료
즉, 신청자 정보 확인, 알림 수단 선택 단계에서 이탈이 많았다는 거였다. 처음에는 화면의 구성에 문제를 찾아 나섰다. 너무 복잡해 가독성이 떨어졌던 건지, 화면에 얼마나 머무르는지, 이탈 후 어떤 여정을 이어갔는지, 다른 액션을 취하진 않는지 등. 물론, 명확한 문제를 찾지 못했다. 근데 생각해 보니, 사용자는 애초에 이 화면을 볼 필요가 없었다. 그 이유는...
2. 신청자 정보 확인
기획 의도 : 서비스 신청에 필요한 주소가 회원 주소와 일치하는지 확인
필요 없는 이유 : 메인 진입 시 모든 인증 절차 완료, 이사 가는 경우 필요하지만, 변경 빈도가 낮음.
3. 알림 수단 선택
기획 의도 : 사용자가 원하는 채널로 정보를 전송하기 위함(알림톡, 앱푸시, 이메일 등)
필요 없는 이유 : 개발 이슈로 채널은 하나만 제공할 수밖에 없는 상황으로 선택의 여지가 없음.
초기 기획 시 바라본 문제를 다시 바라 보니, 문제가 될 게 없었다. 전환 사용자의 각 단계별 user journey에 [다음 버튼 클릭] 외 다른 이벤트는 거의 보이지 않았던 걸 확인하니 더 확신했다. 결국, 우리의 확신은 불필요한 공수를 줄였고 더 빠른 실험을 할 수 있었다.
✅ 간단명료하게 가설 세우기
“사용자 정보 확인과 알림 수단 선택 단계가 없으면 신청을 더 쉽게 할 수 있을 것이다.”라는 가설에 맞춰 Action item은 "플로우 간소화"로 빠르게 결정됐다. 우리는 문제 되는 단계를 제거하기로 했다.
메인 화면 진입 → 서비스 이용 동의 → 신청 완료
✅ 과감하고 안전하게 실험하기
화면단의 개선을 고민했다면 절대 불가능했을 배포 일정이 잡혔다. 화면을 없앰으로써 빠르게 실험할 수 있다는 건 기대됐지만, 동시에 없어진 정보가 사용자에게 더 불편하진 않을까 우려됐다. 그래서 예측 가능한 문제를 리스트업 했고, 이를 방지할 수 있는 장치들을 곳곳에 마련했다.
신청자 정보 및 알림 수단에 대한 간단한 안내 문구 제공
메인 화면 → OO시 OO구 OO동으로 서비스가 신청돼요. 주소가 다르면 변경 후 이용해 주세요.
완료 화면 → 이제부터 매달 카카오 알림톡으로 알려드릴게요.
✅ 실험 지표 설정
실험으로 측정할 수 있는 가설의 성공 여부 판단과 우려한 일이 실제 발생했는지 측정하기 위해 지표를 설정했다.
1. 목표 지표(Primary Metric)
서비스 신청 전환율 및 건수
→ 실험을 통해 직접적으로 개선하고자 한 핵심 지표
→ 전환율 상승 여부를 판단하는 1차 기준
2. 보조 지표(Secondary Metric)
1) 약관 동의 후 신청 완료까지의 전환율
→ 중간 단계 제거가 실제로 사용자 이탈을 줄였는지 확인
2) 신청 프로세스 평균 소요 시간
→ 간소화로 인한 사용자 피로도 감소 여부 판단
3. 가드레일 지표(Guardrail Metric)
1) 신청 직후 해지 건수
→ 과도한 간소화로 인한 잘못된 신청 유입 여부 체크
2) 관련 VoC 인입 건수
→ 신청 과정에서 정보 부족이나 오해로 발생한 민원 확인
✅ 결과와 레슨런(Lesson Learn)
목표한 신청 전환율과 건수는 상승했고, 보조 및 가드레일 지표는 우려와 달리 safe area에서 벗어나지 않았다. 이유 있는 없음은 효과적이었다.
개선 후(위) / 개선 전(아래) 퍼널 비교이번 실험으로 느낀 점
UX 문제를 해결하는 첫걸음은 기획부터 모든 과정을 의심하는 것이고,
때로는 좋은 디자인이기 전에 없는 디자인이 나을 수도 있다는 것.
물론, 매번 이렇게 되리란 법은 없겠지만 시간이 금인 우리는 문제를 찾을 때보다 먼저 “이게 정말 필요한가?”를 의심해보는 태도에서 출발해야 한다.
그 의심 하나가, 복잡한 설계보다 더 빠르고 정확한 해결책이 되어줄지도 모른다.
