점심 공동배달 앱 화면설계 — 각자 결제하고 함께 받는 7개 화면
점심 공동배달의 핵심은 단체 주문이 아니라 개인 결제와 회차 성립을 함께 관리하는 일입니다. 7개 화면의 기능과 남은 검증 과제를 정리합니다.
구내식당이 없는 건물에서 점심을 함께 받자는 아이디어는 주문 버튼 하나로 끝나지 않습니다. 여러 회사 사람이 각자 메뉴를 고르고 결제하되, 최소 식수가 모여야 배송이 성립하고, 정해진 로비에서 각자의 포장만 찾아야 합니다. 이 설계의 중심은 ‘대표가 취합하고 나중에 정산’하는 방식을 없애는 데 있습니다.
화면은 한 건물, 한 점심 회차, 제휴 음식점 2~3곳이라는 시범 운영 가설에서 출발했습니다. 10식 최소수량, 12:00~12:20 수령, 주간 이용 빈도 같은 지표는 검증 전 목표입니다. 실제 배달 성과나 식당 계약을 보여주는 자료가 아니라 기능 정의를 검토하는 초안입니다.
대표 이미지는 실제 산출물 화면에 파일프렌즈 캐릭터를 더한 삽화입니다. 화면 속 날짜·금액·인물은 예시이며, 원문은 아래 공개 링크에서 확인할 수 있습니다.
1. 홈과 회차 상세 — 오늘 가능한 약속을 먼저 고르기
홈은 건물과 오늘의 점심 회차를 찾는 출발점입니다. 회차 상세에서는 주문 마감 시각, 예상 수령 시간, 참여 음식점, 현재 확정 식수와 최소 식수를 보여줍니다. 사용자는 ‘같이 시키면 싸다’는 막연한 기대가 아니라 마감 전 주문하고 성립 여부를 기다리는 구조를 이해해야 합니다.
회차가 성립하지 않을 때 추가 요금을 나중에 청구하지 않고 자동 취소·전액 환불한다는 문구가 중요합니다. 반대로 식당 취소, 조리 지연, 로비 혼잡을 어떤 상태로 알릴지는 더 필요합니다. 배송비 분담 기준과 건물 관리자의 역할도 회차 상세에서 빠지면 안 됩니다.
2. 음식점 메뉴와 주문서 — 개인 선택을 공동 회차에 연결하기
음식점 상세·메뉴 화면은 도시락·국물·추가 필터와 메뉴별 가격, 옵션, 담기 상태를 제공합니다. 오늘 마감된 메뉴는 담을 수 없게 해야 합니다. 메뉴를 고른 뒤 주문서·결제 화면에서 회차 마감, 성립 기준, 결제 수단, 배달비 분담, 수령존과 수령번호 발급 조건을 한 번 더 확인합니다.
결제 총액은 메뉴 가격과 분담 비용을 구분해 보여줘야 합니다. 주문 전 최종 확인 창과 중복 결제 차단은 필수 정의입니다. 하지만 음식점 메뉴 품절을 언제 동기화하는지, 옵션 변경 뒤 금액을 어떻게 재승인하는지, 결제 성공과 식당 수락이 엇갈릴 때 어떤 상태를 우선할지는 실제 연동 전에 결정해야 합니다.
3. 주문완료·수령번호 — 로비에서 찾을 단서를 하나로
주문완료 화면은 주문번호, 결제 상태, 수령 시간대, 수령존, 메뉴와 총액을 다시 보여주고 개인 수령번호를 발급합니다. 번호는 포장에 붙고 수령이 끝나면 같은 번호로 다시 찾을 수 없다는 안내가 있습니다. 로비에서 이름을 크게 부르거나 회사별 대표자를 찾는 과정을 줄이는 장치입니다.
번호만 강조하면 오수령과 분실 대응이 남습니다. 번호 재발급, 동료 대리 수령, 음식이 늦을 때의 안내, 수령 확인 주체가 정의돼야 합니다. 개인정보가 섞인 회사명이나 전화번호를 포장에 얼마나 노출할지도 운영 정책으로 확인해야 합니다.
4. 주문 상태 추적과 환불 내역 — 회차의 실패도 화면에 기록하기
상태 추적 화면은 조리·출발·도착·수령 단계와 11:48 갱신 같은 갱신 시각을 보여줍니다. 실시간 위치 지도는 보이지 않습니다. 상태를 누가 언제 갱신할지 운영 기준을 구체화해야 합니다.
환불 내역 화면은 회차 미성립 자동취소, 식당 취소, 환불 대기, 실패·운영 대기열을 나눠 보여줍니다. 환불액, 주문번호, 예정일과 결제사 대조 상태가 있어야 개인 결제의 불안을 줄입니다. 성립 후 식당 취소 시 해당 주문만 환불하는 규칙은 이미 정의돼 있습니다. 이 규칙을 실제 결제사에 연결하고, 실패·장기 지연 때 책임자와 다음 안내 시각을 구체화해야 합니다.
5. 7개 화면을 검증할 질문
첫째, 총무 취합 없이 5~30인 규모 소기업의 직장인이 개인 결제를 실제로 선택할까요? 둘째, 마감 전 현재 식수와 최소 식수를 보고 주문할까요? 셋째, 메뉴 품절·회차 미성립·배송 지연을 상태 화면만으로 이해할까요? 넷째, 로비의 수령번호가 오수령을 줄일까요? 다섯째, 전액 환불이 실제 결제사 처리 시간 안에 끝날까요?
이 질문에는 건물 한 곳의 파일럿, 식당 수락 로그, 수령 관찰, 환불 대조가 필요합니다. 지금의 7개 화면은 배달망이나 식당 계약을 검증하지 않았고, 성공 지표도 관찰 전입니다. 그래도 주문부터 실패 처리까지 한 흐름으로 놓아야 어디가 제품 문제이고 어디가 운영 문제인지 구분할 수 있습니다. 이 글은 성공담 모음이 아니라 정찰 기록입니다.
