Booking, one question at a time예약, 한 화면에 질문 하나
Play the whole request in the phone. Every screen uses a part from the design kit, so this is what the app would look like. Prices are sample numbers worked out from your picks. Text is Plus Jakarta Sans, the face we picked today.폰에서 요청 전체를 직접 해 보세요. 모든 화면은 디자인 키트의 파트로 만들어서 앱에서도 이렇게 보여요. 가격은 선택에 따라 계산한 예시. 글꼴은 오늘 고른 Plus Jakarta Sans.
Jump to a screen화면 바로가기
For the product call제품 결정에서 정할 것
- Replace the one long form? Today the owner fills pets, place, dates, drop-off and pick-up on one screen. Here each is one screen with one big button.
- Dates: quick picks first, the calendar under them. Full days are struck; Chloe's calendar decides.
- Who drives: asked on its own screen both ways, because it changes the trip and the entry info later.
- Check screen: every answer with Change, and the price from Chloe's rates. Nothing is paid until Chloe says yes.
- Scope: the parts all exist (#279). Building it in the app is about a day: one route, six screens, the existing request call.
- 긴 폼 하나를 바꿀까? 지금은 펫, 장소, 날짜, 맡기기, 데려오기를 한 화면에서 채워요. 여기선 하나씩 한 화면, 큰 버튼 하나.
- 날짜: 빠른 선택이 먼저, 그 아래 캘린더. 꽉 찬 날은 줄 그어짐; 클로이의 캘린더 기준.
- 누가 운전: 오가는 길을 각각 따로 물어요. 트립과 출입 정보가 달라지니까.
- 확인 화면: 모든 답에 Change, 가격은 클로이 요금 기준. 클로이가 수락하기 전엔 결제 없음.
- 범위: 파트는 다 있음 (#279). 앱에 만드는 건 약 하루: 라우트 하나, 화면 여섯, 기존 요청 호출.
Older, all four flows (care request, Meet and Greet, checkout too): Step by step. In the app: /dev/booking-flow on #279.예전 버전, 4개 흐름 전체 (케어 요청, 만남, 결제 포함): Step by step. 앱에서는 #279의 /dev/booking-flow.
All six screens여섯 화면 전체
The same request with the default answers, every step side by side. These are also the boards in Figma (Tickets › Booking flow).기본 답으로 채운 같은 요청, 모든 단계를 나란히. 피그마 보드와 같아요 (티켓 › 예약 흐름).