🌟 디테일의 간격 시리즈! [💖가설로 검증하며 디자인해보기] (👀간단 요약) 이 글에서는 사내 스터디에서 진행한 데이터 분석을 활용해 ‘가설’과 ‘데이터’로 디자인한 경험을 글로 풀어보려고 한다. (👉 Amplitude는 세션 단위로 트래킹 되는 GA와 다르게 이벤트와 사용자의 속성으로 트래킹 되고, Touchpoint로 어느 화면에서 사용자가 접근했는지 확인할 수 있어 사용자의 행동을 분석하기에 좋다.) 📌 문제 파악하기 오일나우는 가장 빠른 주유소 검색 앱이다. 전국 12,000여 개의 주유소 정보를 실시간으로 제공하고 있는데, 정보의 정확도와 최신성을 유지하여 사용자의 신뢰도를 높이는 게 중요하다. 오일나우는 주유소의 24시 영업 여부를 표시해주고 있는데, 앱에서 표기하고 있는 방식에서 문제점을 발견했다. ✓ 오일나우에서 24시 주유소를 찾기 위해서는 [검색]-[주유소 탐색]-[주유소 클릭]-[상세보기]-[24시 표시 찾기] 과정을 거쳐야 한다. 📌 문제 해결하기 ✓ [늦은 저녁엔 24시 주유소로 방문 유도] 오후 8시부터 다음날 오전 6시까지는 주유소가 문을 닫았을 확률이 높다. 이 시간에 주유소를 검색할 경우 24시 주유소로 방문을 유도해야 한다. 20:00~06:00에는 24시 필터가 잘 보이도록 주유소 탐색 화면에 노출시켰다. ✓ [24시 주유소만 모아볼 수 있는 필터] 사용자가 쉽게 기능을 끄고 켤 수 있도록 버튼을 전면에 배치했다. 상단에 [필터] 메뉴가 있음에도, 더 적극적으로 24시 필터를 이용하도록 유도하기 위해 탐색 화면 전면에 배치했다. 📌 가설 세우기 ✓ 24시 필터 기능을 제공하면, 사용자의 주유소 탐색 및 선택 시간을 줄여줄 것이다. 가설을 사용하는 이유는, 의사 결정 시간을 단축하기 위해서다. 모든 정보를 수집하고 분석하여 결론을 도출할 수도 있지만, 시간과 인력이 부족한 스타트업에서는 가설 → 실험 → 검증을 반복하는 프로세스를 이용하는 것이 효율적이다. 📌 데이터 분석하기 [사용자가 앱을 실행]→[주유소를 검색]→[주유소를 탐색]→[주유소까지 길 안내] 이 과업 소요시간이 단축되면, 위 가설은 성립한다. ✓ 분석 조건 설정 목적, 기준 기간, 비교 기간, 분석 모수, 데이터 출처, 분석 조건(이벤트 및 사용자) 등 세부 설정 하기 ✓ 사용자 분류 그룹(1) : ‘24시 필터’ 기능이 추가되기 전, 사용자 그룹(2) : ‘24시 필터’ 기능이 추가된 후, 그룹(1) 중 업데이트를 안한 사용자 그룹(3) : ‘24시 필터’ 기능이 추가된 후, 그룹(1) 중 업데이트를 한 사용자 ✓ 분석 결과 확인하기 평균값(Average Time)은 여러 가지 변수가 있다고 판단하여, 중간값(Median)을 이용해 비교했다. (1)번 그룹의 과업 소요시간의 중간값은 1m37s (2)번 그룹과 (3)그룹의 과업 소요시간은 각각 1m34s, 1m29s 같은 기간에 ‘24시 필터’ 기능을 이용한 사용자가 5초 빨리 주유소를 찾았다. 업데이트 전과 후 기간을 비교했을 때는 무려 8초가 감소했다. 📌 아쉬웠던 점 필터 기능의 이벤트 수를 트래킹하지 못한 점 : 토글 스위치 ON/OFF가 중복 값으로 잡혀서, 기능을 켠 사용자의 유니크 값을 찾기 어려웠다. 좀 더 직접적인, 정확한 데이터를 얻을 수 있도록 설계가 필요하다고 느꼈다. 사용자가 앱을 사용한 시간대를 특정하여 분석하지 못한 점 : 사용자가 이용한 시간대를 한정하여 데이터를 분석했다면 더 의미 있는 결과가 나오지 않았을까 하는 아쉬움이 있다. 📌 좋았던 점 가설과 데이터를 세팅하고, 분석하는 일은 분명 오래걸리고 번거롭다. 하지만 그 과정에서도 배울 점이 있다. 미숙하지만 직접 데이터를 찾아보고, 내 디자인을 검증해가는 과정에서 다음 디자인에 대한 ‘이유’도 더 명확히 할 수 있기 때문이다. (👋중요한 이유가 뭔가요?) 글 말미에, 참고 자료로 책 한권이 들어가 있어요. 저도 읽어본 책인데요. 꼭 데이터 분석이 아니더라도 '가설' 설정이 얼마나 중요한지 알려주는 책 중 하나에요. A기능을 B로 업데이트 된다고 했을 때, 우리가 고려하고 판단해야 할 기준점들은 꽤 많아요. 이를 하나씩 목록화 하고 우리 방법대로 리스트업 하는 것도 좋지만, 기존 대비 어떤 변화가 있을 것이다. 라는 가설을 팀 단위로 설정하는 일이 정말 중요합니다. 앞서 프로덕트 스펙 문서 작성하기라는 글을 코멘트로 작성한 적 있는데요. 프로덕트 스펙 문서 작성 시에도 '가설'이 중요하게 다뤄지는 이유는 업데이트 또는 프로젝트의 특정 기간 동안의 성과를 판단할 수 있는 중요한 기준점이 되기 때문입니다. 우리는 이걸 확인하기 위해 업데이트를 하는거야. 우리는 이런 판단 기준을 통해 해당 기능의 사용성을 확인할거야. 등등 말이죠. 단순히 기능 업데이트에 대한 데이터만 보게 된다면, 판단할 수 있는 기준점을 갖지 못한 채로 잘못된 해석을 하게 될 수 있어요. 예를 들어 해당 기능 덕분에 체류 시간을 늘어났지만, 우리가 바라는 목표 달성율에는 영향이 없다면? 우리팀이 잘했어! 라고 결론지을 수 있을까요?