학원 상담 예약 앱 화면설계 — 7개 화면으로 끊어 본 예약의 앞뒤
학원 탐색부터 예약 취소까지 7개 화면을 따라가며, 화면 유형과 기능정의를 어떻게 연결하는지 정리했습니다.
예약 앱 화면은 예쁜 달력 하나로 끝나지 않습니다. 학부모가 학원을 찾고, 빈 시간을 고르고, 정보를 남기고, 예약을 바꾸거나 취소하는 모든 순간이 이어져야 합니다. 이번 화면설계는 그 흐름을 7개 화면으로 잘라 확인하는 작업입니다.
결론부터 말하면 화면 수보다 중요한 것은 화면 사이의 상태입니다. 탐색 화면의 ‘가능’이 예약 플로우의 선택으로 이어지고, 예약 목록의 ‘확정’이 상세 화면의 변경·취소로 이어져야 합니다. 아래 예시는 김포 지역 초등 영어·수학 학원을 가정한 프로토타입입니다. 이름, 날짜, 예약번호, 지표와 정책 문구는 생성 시점의 가상 시나리오이며 실제 운영 정책이나 검증 결과가 아닙니다.
대표 이미지는 실제 산출물 화면에 파일프렌즈 캐릭터를 더한 삽화입니다. 화면 속 날짜·금액·인물은 예시이며, 원문은 아래 공개 링크에서 확인할 수 있습니다.
7개 화면은 예약 여정을 어디서 끊는가
첫 화면은 홈입니다. 오늘과 이번 주 빈 시간을 요약해 탐색의 진입점을 만듭니다. 목록(학원탐색)은 장기동·구래동 학원을 과목과 시간대별로 좁히고, 상세(학원탐색)는 학원 소개와 빈 시간 달력을 한곳에 모읍니다. 여기서 상담 40분, 체험 50분, 잔여 자리와 마감 상태가 보입니다.
네 번째 화면은 상담·체험 예약플로우입니다. 시간 선택, 보호자·아이 정보 입력, 예약 확정의 3단계를 한 흐름으로 보여 줍니다. 다섯 번째 목록(내 예약 내역)은 확정·대기·취소를 필터링하고, 여섯 번째 상세(내 예약 내역)는 방문까지 남은 시간과 잔여 정원, 변경·취소 버튼을 제공합니다. 마지막 예약취소 확인 모달은 사유와 추가 내용을 받으며, 실제 취소 직전의 판단을 한 번 더 묻습니다.
화면 유형을 나누면 빠진 상태가 보입니다
IA에는 화면, 섹션, 모달, 흐름이 함께 적혀 있습니다. 화면은 독립적으로 이동하는 장소이고, 섹션은 홈의 빈 시간 요약처럼 한 화면 안에서 정보를 묶는 단위입니다. 모달은 예약 확인이나 취소처럼 현재 맥락을 유지한 채 결정을 받아야 할 때 씁니다. 흐름은 여러 단계의 순서를 설명하므로, 단일 화면 캡처만 보고는 놓치기 쉬운 입력과 검증을 드러냅니다.
이 구분은 작업 분량을 부풀리기 위한 분류가 아닙니다. 예를 들어 ‘예약 취소’를 화면으로만 적으면 취소 사유, 닫기, 재오픈되는 슬롯, 반복 취소 안내가 빠질 수 있습니다. 모달이라는 유형을 먼저 정하면 필요한 상태와 다음 동작을 함께 점검하게 됩니다.
기능정의는 버튼 설명보다 상태의 약속입니다
예약취소 확인 모달의 기능정의는 일곱 가지 동작으로 내려갑니다. 취소하면 해당 시간이 다시 빈 시간으로 열린다는 안내, 학원·일시·아이·방문까지 남은 시간의 재확인, 취소 사유 단일 선택, 추가 내용 입력, 취소 기한과 반복 취소 안내, 취소하지 않고 닫기, 최종 취소 처리까지입니다. 이 문장은 개발자에게 버튼 위치보다 시스템이 해야 할 일을 전달합니다.
‘가능’, ‘선택’, ‘마감’, ‘확정’, ‘대기’, ‘취소’도 같은 방식으로 정의해야 합니다. 상태가 바뀌면 어떤 문구가 바뀌고, 어떤 버튼이 활성화되며, 목록과 상세가 어떻게 동기화되는지 적습니다. 현재 프로토타입의 ‘당일 취소는 노쇼로 집계될 수 있습니다’와 ‘방문 하루 전까지 취소’ 문구는 예시 카피입니다. 최종 정책으로 확정된 내용이 아니며, 실제 서비스에서는 운영자·법무·고객지원 기준을 따로 확인해야 합니다.
취소 기준도 목록의 24시간 전, 상세의 하루 전 18시, 모달의 하루 전이 혼재합니다. 단순히 예시라고 표시하는 데서 끝내지 않고, 하나의 운영 기준을 정한 뒤 목록·상세·모달 문구를 통일해야 합니다.
프로토타입에서 운영 화면까지 이어지는 질문
화면을 검토할 때는 세 가지를 묻습니다. 첫째, 사용자가 지금 무엇을 선택했고 다음에 무엇을 기대하는가. 둘째, 잔여 정원 0명이나 중복 예약처럼 실패하는 경우에도 이해할 수 있는가. 셋째, 학원 운영자가 예약 확정·노쇼·시간표 변경을 실제로 처리할 수 있는가. 이 질문을 통과해야 화면이 서비스의 약속이 됩니다.
이번 예시는 홈부터 취소 모달까지의 앞단과 뒷단을 함께 담았지만 예약 기능이 구현되었거나 테스트되었다는 뜻은 아닙니다. 실제 개발 전에는 인증, 알림, 동시 예약 잠금, 시간대 기준, 취소·노쇼 정책을 별도 확정해야 합니다. 화면은 출발점이고 기능정의는 그 출발점에 운영 규칙을 연결하는 지도입니다.
