23장 예약 interaction을 happy path 밖에서 설계한다
멋진 정적 landing page도 예약 순간에 신뢰를 잃을 수 있다. Interaction 품질은 animation의 매끄러움보다 사용자가 현재 상태와 다음 결과를 아는가에 달려 있다.
예약 흐름을 상태 기계처럼 쓴다.
idle → dialog_open
dialog_open → validating
validating → field_error | checking_availability
checking_availability → conflict | ready
ready → submitting → success | network_error
conflict → choose_another_slot → checking_availability
network_error → retry | save_contact
이 상태를 prompt에 넣지 않으면 AI는 alert('예약 완료') 같은 happy path를 만든다. UI 문구도 상태마다 답해야 한다.
| 상태 | 사용자가 알아야 할 것 | 다음 행동 |
|---|---|---|
| validating | 어느 값이 왜 필요한가 | field 수정 |
| checking | 요청이 접수됐고 얼마나 기다리는가 | 중복 click 방지 |
| conflict | 그 사이 자리가 찼음 | 다른 시간 선택 |
| network error | 입력 문제가 아님 | 다시 시도·문의 |
| success | 예약 번호·날짜·결제 여부 | 일정 저장·닫기 |
교육용 Onda 화면은 서버로 전송하지 않는다. 그래서 button은 선택 내용 확인, notice는 결제는 진행하지 않으며 입력값은 저장되지 않습니다라고 명확히 쓴다. 실제 동작보다 더 큰 결과를 약속하지 않는 것도 디자인 품질이다.
Form 검수 순서는 다음과 같다.
- field를 비운 채 제출해 오류의 위치·문장·focus를 본다.
- IME로 한글을 조합하고 Enter가 조합 중 제출하지 않는지 본다.
- paste, autofill, password manager가 layout을 깨지 않는지 본다.
- 느린 network에서 button이 busy가 되고 중복 요청이 막히는지 본다.
- server 오류 뒤 입력값이 보존되는지 본다.
- 성공 뒤 뒤로 가기와 새로고침 결과가 안전한지 본다.
AI가 interaction code를 수정했다면 screenshot만 승인하지 않는다. 정상·오류·취소·재시도 네 경로를 실행하고, console error와 network request를 함께 기록한다.