[프로젝트 100] Day36. 스매시맵 프론트 기획

오늘은 스매시맵 예약 페이지를 다시 봤다.

처음에는 예약 페이지에서 부족한 부분이 뭔지 정도만 보려고 했는데, 막상 정리하다 보니 단순히 화면 하나를 고치는 문제가 아니었다. 예약을 받는 고객 화면과 실제로 예약을 처리하는 점주 화면이 같이 맞물려야 했다.

오늘 가장 크게 정리한 건 예약 흐름의 기준이다.

오늘 작업한 것

• 예약 페이지에서 부족한 부분을 다시 분석했다.
• 방문 예약과 수거/배송 예약의 표현을 분리했다.
• 예약 상세 화면이 필요하다고 보고 흐름을 정리했다.
• 가격은 고객 화면에서 미리 보여주지 않는 방향으로 정했다.
• 마이페이지 안에 내 정보 관리, 내 활동, 고객센터, 약관 영역을 나눴다.
• 점주 화면을 만들기 위한 새 채팅용 정리 문서를 만들었다.

앱 메인

오늘 결정한 것

스매시맵에서 고객이 예약할 때 가격을 바로 확정해서 보여주는 건 아직 맞지 않다고 봤다. 스트링 작업은 매장마다 기준도 다르고, 라켓 상태나 요청 내용에 따라 실제 비용이 달라질 수 있기 때문이다.

그래서 고객 화면에서는 예약을 먼저 받고, 점주가 예약을 확인한 뒤 실제 비용을 안내하는 흐름이 더 자연스럽다고 정리했다.

또 하나 결정한 건, 관리자 화면보다 점주 화면을 먼저 만드는 것이다. 지금 필요한 건 플랫폼 전체 관리보다 실제 예약을 처리하는 흐름이다. 고객이 예약을 넣었을 때 점주가 그걸 확인하고, 상태를 바꾸고, 비용을 입력할 수 있어야 서비스가 이어진다.

막혔던 부분

처음에는 예약 페이지 안에서만 생각했다. 그런데 계속 보다 보니 고객 화면만으로는 해결이 안 되는 부분이 많았다.

예를 들어 예약 가능 시간, 작업 마감, 비용 안내, 스트링 옵션 같은 것들은 결국 매장 쪽에서 관리해야 한다. 고객 화면에 예쁘게 보여주는 것보다, 점주가 어떤 값을 넣고 어떻게 처리할지가 먼저 잡혀야 했다.

알게 된 것

오늘 느낀 건 예약 서비스는 화면보다 운영 흐름이 먼저라는 점이다.

고객 입장에서는 간단히 예약하는 것처럼 보여야 하지만, 그 뒤에는 점주가 확인해야 할 정보가 꽤 많다. 방문인지, 수거/배송인지, 어떤 스트링을 원하는지, 작업 시간이 가능한지, 실제 비용은 얼마인지 같은 것들이다.

결국 지금 단계에서 중요한 건 기능을 많이 붙이는 게 아니라, 고객 화면과 점주 화면 사이의 연결 기준을 잡는 거였다.

다음에 할 것

• 점주용 예약 관리 화면을 먼저 만든다.
• 예약 상태 변경, 비용 입력, 작업 시간 관리 흐름을 잡는다.
• 관리자 화면은 점주 화면이 어느 정도 잡힌 뒤에 다시 본다.

오늘은 화면을 크게 만든 날이라기보다는, 스매시맵 예약 기능이 실제 서비스처럼 굴러가려면 어떤 구조가 필요한지 정리한 날이었다.아직 갈 길은 있지만, 그래도 오늘 정리하면서 방향은 조금 더 선명해졌으며, 이제 진도 팡팡 나갈옞정이다.