로그 데이터가 0건인 환경에서 디자인 근거를 만든 방법 — Maze로 히트맵 한 장 띄웠더니 회의가 달라졌다

"예전에 이런 게 잘 됐었어." "이 정도면 사용자도 이해하지 않을까요?"

프로덕트 디자이너가 가장 자주 마주하는 벽이 뭔지 아세요? 데이터의 부재예요. 데이터 분석 인프라가 완벽히 갖춰진 환경은 생각보다 많지 않거든요. 로그가 쌓이지 않은 초기 스타트업, 분석 툴을 도입하기 어려운 보안 환경, 기술적 제약이 있는 레거시 시스템. 이런 곳에서는 의사결정이 자연스럽게 '경험'이나 '직관'에 의존하게 되죠.

문제는 그 판단이 맞고 틀리고가 아니에요. 가설을 객관적으로 확인할 방법 자체가 없다는 거예요. 사용자가 어디에서 멈추고 뭘 놓치는지, 단 한 번이라도 직접 확인하고 싶었어요. 상황을 탓하며 인프라가 구축되길 기다릴 수만은 없었고요.

로그가 없으면 '가상의 실험장'을 만들면 된다

서비스에 로그가 심겨 있지 않다면? 사용자의 행동을 관찰할 수 있는 가상의 실험장을 직접 구축하기로 했어요. 인터랙션이 구현된 고도화된 프로토타입을 활용해 데이터를 수집하는 전략이었습니다.

선택한 도구는 Maze였어요. 툴 자체가 정답이라기보다, 정성과 정량 데이터를 동시에 수집할 수 있는 가장 빠른 대안이었기 때문이죠.

활용한 기능은 세 가지예요. 히트맵으로 사용자가 의도치 않은 곳을 클릭하는지 확인하고, 성공률과 퍼널로 어느 단계에서 중도 포기하는지 숫자로 파악하고, 주관식 피드백으로 숫자 뒤에 숨겨진 진짜 불편함을 청취했어요.

Nielsen의 연구에 따르면 5~7명의 사용자만 테스트해도 주요 사용성 문제의 약 80%를 발견할 수 있어요. 초기 테스트에 8명의 참가자를 모집했고, 이 과정에서 얻은 데이터들은 시각화된 리포트로 제공됐어요. 솔직히 놀란 건 이거였어요 — "이 부분이 문제인 것 같다"는 긴 설명보다, 히트맵 한 장을 회의실 화면에 띄우는 게 훨씬 강력했다는 거. 동료들과 비로소 '주관'이 아닌 '사실'을 보며 논의할 수 있게 됐죠.

프로토타입 A/B 테스트 — "이탈률 30% 감소"라는 숫자가 나왔다

데이터를 확인한 후에는 개선안을 반영해서 다시 테스트했어요. 실제 서비스 환경은 아니었지만, 동일한 사용자군에게 동일한 미션을 주고 개선 전과 후를 비교한 거예요. A/B 테스팅의 기본 원리를 프로토타입 단계에 적용한 셈이죠.

결과는 명확했어요. 주관적 가설이 "핵심 전환 지점에서의 이탈률이 30% 감소했다"는 구체적인 지표로 바뀌었거든요.

물론 프로토타입 테스트에는 한계가 있어요. 네트워크 속도, 실제 데이터의 복잡성, 사용자의 멘탈 모델 — 통제된 테스트에서 완벽히 재현하기 어려운 변수들이 존재하니까요. 하지만 '방향성'을 검증하기에는 충분했어요. (완벽한 데이터를 기다리다간 아무것도 못 하잖아요.)

데이터가 생기자 회의의 풍경이 달라졌어요. '누구의 의견이 더 설득력 있는가'를 겨루던 소모적인 논쟁이 사라졌어요. "어떻게 더 나은 가치를 줄 것인가"에 집중하는 생산적인 대화가 시작된 거죠. 디자인 결정에 명확한 근거를 가질 수 있게 됐고요.

상황에 맞는 도구를 고르면 된다 — 의외로 선택지가 많다

로그 기반 분석 툴을 바로 쓸 수 없을 때, 디자이너가 활용할 수 있는 도구는 생각보다 다양해요. 각 도구의 특성을 이해하고 서비스 환경에 맞춰 선택하는 게 중요하죠.

Maze 외에도 UserTesting, Hotjar, Lookback 같은 도구들이 있고, 프로젝트 특성에 따라 맞는 걸 골라 쓰면 돼요.

결국 이 경험에서 깨달은 건 하나예요. 데이터는 누군가를 이기기 위한 무기가 아니라는 것. 팀원 모두가 '같은 문제를 같은 방향에서 바라보게 해주는 공통 언어'에 가까워요. 데이터가 부족한 환경일수록 디자이너가 더 적극적으로 사용자의 목소리를 듣기 위해 움직여야 하고요.

완벽한 환경을 기다리기보다 지금 당장 할 수 있는 작은 검증부터 시작하는 것. 그 체계적인 접근 자체가 환경과 상관없이 프로덕트 디자이너로서 지켜야 할 가장 중요한 역량이라고 믿어요.