[ 본 포스팅은 PC 환경에서 보시길 권장합니다 ]
앞서 W4D3에서 공부한 내용을 정리하였다.
그럼 이번 2탄 글에서는 공부한 내용을 적용해 보는 시간을 가져보도록 하자.
W4D3 내용이 궁금하다면 아래 링크에서 확인해 보자👇
2023.03.02 - [PM삐약이🐥] - [코드스테이츠 PMB부트캠프 17기] W4D3_UX 설계, 와이어프레임과 프로토타이핑 1탄
[코드스테이츠 PMB부트캠프 17기] W4D3_UX 설계, 와이어프레임과 프로토타이핑 1탄
갑자기.. 뜬금없이 감기에 걸려버렸다😥 코맹맹이 소리에 정신은 멍하다..ㅠ 그래도 존버,,해보자..! 제품 개선하기 개선하기 쉽도록 서비스를 콘텐츠, 정보, 단계, 인터페이스, 상호작용, 기능
chaemrry.tistory.com
과제: 프로덕트의 사용자 행동 경로(User Flow) 파악 후, 산출물 만들어보기(Wireframe, PRD)
분석할 프로덕트 선정: 캐치테이블
https://play.google.com/store/apps/details?id=co.kr.catchtable.android.catchtable_app&hl=ko&gl=US
캐치테이블 - Google Play 앱
전화없이 간편하게! 핫한 레스토랑 예약
play.google.com
https://apps.apple.com/us/app/%EC%BA%90%EC%B9%98%ED%85%8C%EC%9D%B4%EB%B8%94-catchtable/id1485193566
캐치테이블
■ 200만 이상 유저가 선택한 레스토랑 예약 앱 파인다이닝, 핫한 맛집 등 5,000여 개의 레스토랑 예약이 가능합니다. ■ 전화 필요 없이 APP에서 24시간 실시간 예약 날짜, 시간, 인원 등 원하는
apps.apple.com
유저 플로우:
캐치테이블의 메인 기능이라고 하면, 24시간 언제든지, 유저가 원할 때 레스토랑을 예약할 수 있다는 것이다. 따라서 메인 기능에 따라 시작부터 끝까지의 유저 플로우를 그려봤다.
메인 기능에 충실히 따르기 위해, 왼쪽과 같이 퍼소나를 설정하여 전과정을 구현했다. 위 유저 플로우 그림 중 5번에 해당하는 '데이트코스 선택'은 퍼소나에 맞춰서 설계된 것이나, 어떤 테마를 메인에서 선택하든 뒤에 이어지는 플로우는 동일하다는 점을 먼저 알린다.
개선이 필요한 부분:
1) 로그인
최종 업데이트일이 2022년 12월 7일이라고 나와있는데, 그 이후부터 유난히 '로그인 오류'에 대한 리뷰가 많이 달리고 있는 것을 구글플레이스토어에서 확인할 수 있었다. 이는 위 유저 플로우 이미지에서, 3번, 12번, 22번 기능에 대한 오류이다. 나도 오랜만에 캐치테이블 앱을 분석해보기 위해 앱을 업데이트하고 접속을 했는데, 로그인 시도 시 위 이미지와 같이 노출되어 당황했다. 네이버로도 로그인을 시도했으나, 이미 가입된 메일 계정이라고 로그인이 되지 않았다.
캐치테이블은 로그인을 하지 않은 상태에서도 우선 앱을 탐색할 수 있다. 따라서 나도 그냥 처음에 로그인을 포기하고 앱 메인이랑, 유저 플로우를 생각하기 위해 앱을 살펴보다가, 괜찮아보이는 식당을 클릭해 리뷰를 살펴보려고 했으나, 로그인을 한 유저에게만 리뷰가 노출되어, 어쩔 수 없이 로그인을 다시 시도했다. 전화번호로도 롤그인을 시도해봤고, 비밀번호 변경도 시도해봤는데, 역시 로그인이 되지 않았다.. 그러다가 몇 번의 시도 끝에..얼떨결에 로그인이 되었고, 로그인이 된 상태로 앱을 살펴 볼 수 있었다...(뭐하자는거지??)
플레이스토어 리뷰에도 이렇듯 로그인 버그에 대한 불만이 많은데, 만약 로그인이 원활하게, 간편하게 되지 않는다면, 분명 UX에 큰 영향을 미칠 것이고, 이탈을 막지 못할 것으로 생각된다.
2) 예약금 관리
캐치테이블은 식당마다 예약금을 받을 것인지, 얼마를 받을것인지 정할 수 있게 했다. 하지만 캐치테이블의 이러한 '방치'는 유저에게 큰 불편함으로 돌아가고 있었다는 것을 리뷰와 후기, 네이버 지식인을 통해 확인할 수 있었다. 예약금과 관련된 프로세스는 유저 플로우 이미지에서 23번에 해당된다.
예약금을 받는 레스토랑이라면, 유저가 해당 레스토랑을 예약하려고 할 때 시스템상 자동으로 예약금을 부과하게 한다. 그리고 이 예약금은 바로 레스토랑으로 넘어가는 것을 파악된다. 이러한 구조는 식당과 유저를 직접적으로 연결해준다는 점에서 장점이 있지만, 장점보다 단점이 더 큰 것으로 보였다.
단점은 예약 취소를 할 때 잘 나타난다. 유저가 일정상의 변동 또는 다른 불가피한 사유로 예약 취소를 신청하고, 예약금 환불을 기다리는데, 카드사마다 정책상 환불이 1-2일 늦어지는 것은 알고 있으나, 식당이 환불을 해주는 타이밍이 일정하지 않다. 일주일이 넘게 기다린 고객도 있다고 한다. 식당에서 예약금 환불을 늦게 해주면, 그들에게 주어지는 어떠한 패널티도 없는 것으로 보였다. 어떻게 보면 유저에게 편리함을 제공해준다는 명목하에, 이득을 보는 것은 오히려 식당인 것 같이 느껴졌다.
3) 예약 확정 오류
예약 확정 오류는 유저 플로우 이미지에서 24번에 해당된다.
앞서 2)번 개선점에서도 예약금 관련해서 캐치테이블이 유저가 원활하게 앱을 사용하는 것에 있어 필요한 조치를 취하고 있지 않다고 말했었다. 하지만 예약금 뿐만 아니라, 서비스를 보았을 때 앱을 사용하는 유저에게 불리한 부분이 많다는 것을 알 수 있었다.
어쩌면 캐치테이블은 그들의 핵심 타겟 고객을 식당, 업체로 생각했을 수도 있겠다 싶을 정도이다. 실제로 식당을 예약하려고 하는 유저에게는 CS도 잘 이뤄지지 않고, 예약자가 시스템 오류, 또는 업체 과실로 갑자기 예약 취소를 당하는 것도 손을 놓고 있는 것으로 보였다.
이는 유저와의 신뢰를 깨는 행동으로 생각된다. 유저는 예약금까지 지불하면서 캐치테이블로 예약을 했는데, '예약 확정'이 됐는지 여부는 정작 당일에 가봐야지 알 수 있는 것이다.
3)번 '예약 확정' 개선점도 2)번 '예약금' 개선점과 연관이 있다. 즉, 예약자가 예약금만 지불하면 식당측 확인없이 바로 예약되는 플로우가 문제가 되는 것이다. 예약 확정이 되었다고 했다가, 갑자기 안된다고 하면, 유저는 그저 황당할 뿐, 어떻게 할 수 있는 방법이 없다.
가장 시급한 문제의 개선점을 와이어프레임으로 제작해보기
개선해야할 부분을 '팀원'과 공유하기 위해 와이어프레임을 제작해보았다. 앞서 설명한 문제를 해결하고자, 예약을 수락하는 과정을 중간에 추가한 것이고, 이 과정에서는 예약금을 캐치테이블이 갖고 있다가, 수락되는 즉시 예약금을 식당에 전달하고, 유저에게는 예약이 확정되었다는 알림을 보낸다. 수락 전에 유저가 예약을 취소하더라도, 예약금은 캐치테이블이 갖고 있기 때문에, 환불정책에 따라, 환불일에도 더 이상 편차가 없어질 것이다.
'마이다이닝' - '나의 예약'에는 유저가 요청한 내역이 추가된 '예약 요청'탭에 나타나게 되고, 해당 단계에서 수락이되면 다음 단계인 '방문예정'탭으로 넘어가게 된다.
PRD(제품 요구사항 문서), 기획 산출물 작성:
1. 요약 및 배경(Summary and Background) :
문제는 앞서 설명했듯이, 고객이 예약금을 지불하면 업체 확인 절차 없이 바로 '예약 확정'이 된다는 점이다. 이 플로우가 제대로 작동하려면, 업체의 예약 확인 시스템과 캐치테이블의 시스템이 잘 연동이 되어야 할 것으로 생각되는데, 그렇지 않다는 것을 앞서 확인할 수 있었다. 업체는 네이버예약, 캐치테이블 예약, 전화 예약 등 기타 예약 시스템을 사용할 수도 있어, 중복 예약이 되는 상황도 일어날 수 있다. 그렇게 되면, 예약자는 예약금 지불에 따른 '예약확정'을 확인했음에도 예약 취소를 당해야만 하는 일이 일어나게 된다(실제로 빈번하게 일어나고 있다). 그리고 캐치테이블은 예약 취소에 대한 책임을 그냥 업체측에게만 전가하고 있어, 예약자에게 어떠한 보상도 해주지 않고 있다. 따라서 예약자가 예약금을 지불하면, 예약금을 수령하겠다는 업체의 확인이 있고, 그 뒤에 예약이 확정되는 플로우가 더 적절한 것으로 보인다. 배달 앱을 참고하면 좋을 것 같다.
2. 주요 사용자(Target Users) :
사용자는 2030 연령대 사용자가 73.2%로 가장 눈에 띄었고, 그중에서도 30대 남성과 여성의 비중이 매우 높았다. 이들은 금전적인 여유가 있고, 음식의 퀄리티를 중요하게 생각하는, 즉 맛있는 음식에 대한 니즈가 있는 사람들이다.
캐치테이블에 등록된 많은 식당은 높은 가격대에 형성되어있기 때문에, 지불 능력이 있는 30대 고객을 놓치게 된다면, 비즈니스적으로 큰 타격이 있을 것으로 생각된다.
3. 핵심 사용자 여정(Critical User Journeys (CUJs)) :
'예약자 예약금 지불>>업체 예약 가능 확인 및 예약금 수령>>예약확정'의 플로우로 문제를 해결한 후, 금전적인 여유가 있고, 맛있는 음식에 대한 니즈가 있는 30대는 원하는 식당을 선택해 예약금을 선지불하고, 최대 24시간 내 업체측 확인을 거쳐, 예약 확정 또는 예약 실패를 하게 된다. 지불된 예약금은 배달 앱, 번개장터와 같이 중간 업체로 캐치테이블이 우선 수령하고 있다가, 업체의 예약 승인이 확인되면 업체로 전달해주고, 예약 거절이 되면 캐치테이블은 수령한 예약금을 예약자에게 환불해주게 된다.
주의할 것은 해당 플로우는 예약자가 예약을 취소하는 플로우랑 다르다는 것이다. 예약자가 예약을 취소하게 될 경우, 예약금은 캐치테이블에서 정한 환불정책에 따라 환불이 될 것이고, 필요하다면 이 플로우에 대해서도 수정할 수 있겠지만, 우선순위는 위에서 설명한 업체에 의한 예약 취소 건이라고 생각한다.
4. 기능적 요구사항(Functional requirements) :
우선 '예약 확인 중' 상태 페이지가 필요하다. 예약금 결제 완료 후, '예약금 결제가 완료되었습니다'라는 상태 페이지가 뜨고, 그 아래 '예약이 확정되면 알림을 드릴게요!' 문구를 추가한다. 그리고 해당 상태 페이지는 '마이페이지'에서도 확인할 수 있도록 해야한다. 예약 확정이 되면 해당 상태 페이지에는 '예약 확인 중'이 아닌 '예약 확정'이라고 노출되고, 고객에게 카톡으로 알림을 보내주도록 한다.
캐치테이블 내부 시스템에 수금/송금 로직을 짜야할 것으로 생각된다. 중간에서 캐치테이블이 예약금을 수령하고 있다가, 업체에게 전달해주거나, 예약금을 고객에게 환불해주는 프로세스가 구현될 수 있어야 한다.
-끝-
그럼 내일 다시 만나자!
