예약 시스템 어드민 화면, 정보 구조부터 잡기

 

예약 시스템 기획을 하다 보면 고객이 보는 예약 화면에 신경이 먼저 가기 쉽습니다.
그런데 막상 서비스가 돌아가기 시작하면 매일 가장 오래 들여다보는 건 운영하시는 분들이 쓰는 어드민 화면이에요.
예약이 아무리 잘 들어와도, 어드민에서 확인하고 고치고 처리하는 일이 불편하면 서비스는 금방 외면받습니다.
이 글에서는 어드민 화면을 그리기 전에 정보 구조부터 잡으면서 정리한 생각을 기록해봅니다.

 

처음에는 기능 목록을 그대로 메뉴로 만들었습니다.
예약 관리, 고객 관리, 서비스 관리, 직원 관리, 통계, 설정 같은 식이에요.
틀린 구조는 아니지만, 이대로 두면 운영자의 하루와 메뉴가 맞지 않는다는 걸 곧 알게 됐습니다.

그래서 운영하시는 분이 하루에 하는 일을 순서대로 적어봤습니다.
가정 예시로 동네 미용실 원장님의 하루를 생각해보겠습니다.
아침에 출근해서 오늘 예약이 몇 건인지, 누가 몇 시에 오는지 확인합니다.
영업 중에는 전화로 들어온 예약을 직접 등록하거나, 손님이 늦는다는 연락을 받고 시간을 조정합니다.
마감 후에는 내일 예약을 훑어보고, 노쇼가 있었다면 기록해두고, 가끔 서비스 가격이나 휴무일을 수정합니다.

이 순서로 보면 가장 자주 쓰는 것은 "오늘의 예약 현황"이고, 서비스 가격이나 직원 정보 수정은 가끔 쓰는 기능입니다.
그래서 메뉴 구조를 "오늘", "예약", "고객", "설정" 정도로 단순하게 두고, 가끔 쓰는 기능은 설정 아래로 내리는 쪽이 낫겠다고 정리했어요.
자주 쓰는 기능과 가끔 쓰는 기능을 같은 무게로 나열하지 않는 것이 정보 구조의 핵심이라고 느꼈습니다.

 

예약 시스템의 어드민은 본질적으로 시간 위에 놓인 데이터를 다루기 때문에, 목록보다 캘린더가 중심이 되는 편이 자연스럽습니다.
목록은 "누가 예약했는지"를 보기에 좋고, 캘린더는 "언제 비어 있는지"를 보기에 좋습니다.
운영자가 가장 자주 하는 질문이 "이 시간에 자리가 있나?"라서 캘린더가 맞는다고 봤어요.

캘린더 화면을 기획할 때 정해야 할 것들이 꽤 많았습니다.
일, 주, 월 보기 중 무엇을 기본으로 둘지, 직원이나 룸 같은 자원별로 열을 나눠 보여줄지, 예약 블록에 어떤 정보까지 노출할지입니다.
예약 블록에 고객 이름과 서비스 이름, 상태 정도만 보이게 하고, 자세한 내용은 클릭했을 때 옆 패널에 보이게 하는 식으로 정리했습니다.
상태는 색으로 구분하는 게 편한데, 색만으로 구분하면 접근성 문제가 있어서 아이콘이나 글자도 함께 쓰자는 메모를 남겨두었습니다.

빈 시간에서 바로 예약을 등록하는 흐름도 중요합니다.
캘린더의 빈 칸을 눌렀을 때 시작 시간이 미리 채워진 등록 창이 열리면, 전화로 받은 예약을 몇 번의 입력만으로 넣을 수 있어요.
반대로 예약 블록을 드래그해서 시간을 옮기는 기능은 편리하지만, 옮길 때 고객 알림을 보낼지, 겹치는 예약이 있으면 막을지 같은 정책 질문이 따라붙어서 따로 정의해두어야 합니다.

 

어드민 화면은 한 건씩 처리하는 흐름만으로는 부족한 순간이 옵니다.
갑작스러운 휴무일이 생기면 그날의 예약 열 건을 한꺼번에 취소하고 고객에게 알려야 할 수도 있어요.
이럴 때 예약을 하나씩 열어서 취소하게 하면 운영자는 같은 일을 열 번 반복해야 합니다.
그래서 목록에서 여러 건을 선택해 일괄 처리하는 기능, 특정 기간을 휴무로 설정하면 기존 예약을 어떻게 처리할지 물어보는 흐름을 기획에 넣어두었습니다.
대량 처리는 실수했을 때 피해도 크기 때문에, 처리 전에 대상 건수와 영향을 보여주는 확인 단계가 꼭 필요하다고 생각해요.

또 하나는 모바일입니다.
소규모 업장의 운영자는 책상 앞에 앉아 있는 시간이 길지 않고, 손님을 응대하면서 휴대폰으로 예약을 확인하는 경우가 많을 것 같아요.
그래서 어드민을 데스크톱 기준으로만 설계하지 않고, 모바일에서 꼭 필요한 기능을 먼저 추려보았습니다.
오늘 예약 확인, 예약 상태 변경, 새 예약 간단 등록, 알림 확인 정도가 모바일에서 우선순위가 높은 기능이었습니다.
반대로 통계나 복잡한 설정은 데스크톱에서 해도 괜찮다고 판단했어요.
이렇게 나누면 모바일 화면은 작은 데스크톱이 아니라, 하루 중 빠르게 확인하고 처리하는 용도로 따로 설계할 수 있습니다.

 

정보 구조가 잡힌 다음에는 화면정의서를 쓰는데, 어드민은 화면 수가 많아져서 요령이 필요했습니다.
제가 쓰는 방식은 화면마다 목적, 진입 경로, 보이는 데이터, 가능한 동작, 빈 상태, 오류 상태를 같은 순서로 적는 것입니다.
특히 빈 상태를 빼먹지 않으려고 해요.
예약이 하나도 없는 날의 화면이 어떻게 보일지, 처음 가입한 업장이 서비스를 아직 등록하지 않았을 때 무엇을 안내할지까지 적어두면, 개발 단계에서 "이건 어떻게 해요?"라는 질문이 줄어듭니다.

권한에 따라 화면이 달라지는 경우도 표시해둡니다.
같은 예약 상세 화면이라도 직원에게는 고객 연락처가 가려지고 관리자에게만 보인다면, 그 차이를 화면정의서에 한 줄씩 적어야 해요.
이 부분은 권한 모델 기획과 이어지는 내용이라 다른 글에서 따로 다룰 예정입니다.

 

어드민 화면은 화려할 필요는 없지만, 운영자의 하루를 이해하고 있다는 느낌이 들어야 한다고 생각합니다.
아직 정리하지 못한 질문도 있어요.

업장이 여러 개인 운영자는 업장 전환을 어디에 두어야 하는지, 알림이 많아질 때 어드민 안의 알림함을 어떻게 정리할지 같은 것들입니다.
실제로 운영하시는 분들의 이야기를 더 듣고 보완해야 할 부분이라고 생각해요.