전송의 상태
입력 가능·검증 실패·전송 중·성공·실패와 결과 불명을 구분합니다. 상태가 바뀌었을 때 화면과 보조기술이 그 사실을 이해할 수 있는지 확인합니다. 처리 중을 성공처럼 표시하거나 응답 전에 폼을 비우지 않습니다.
가정한 동작 명세
아래는 검수용 상태표이며 실제 중복 방지 코드가 아닙니다. 서버의 업무 식별과 원장 처리는 별도 설계해야 합니다.
idle: submit allowed after valid input
pending: one request active, visible processing message
rapid click: no additional request from same pending action
Enter key while pending: no additional request
confirmed success: show completion, avoid automatic resubmission
confirmed failure: retain safe input, allow documented retry
unknown result: explain uncertainty, check before creating duplicate
실패 복구
가정한 예로 네트워크 오류 후 버튼이 영구히 비활성화되면 고객은 입력을 잃거나 다시 방문해야 합니다. 실패 상태를 복구하고 입력이 남는지 확인합니다. 서버가 이미 저장한 뒤 응답이 끊기는 경우에는 단순 새 요청을 반복하게 하지 않도록 정책이 필요합니다.
검수 순서
- 느린 성공 응답을 모의해 처리 중을 봅니다.
- 연속 클릭·Enter·다른 제출 버튼을 시험합니다.
- 실패 뒤 재활성화와 입력 보존을 확인합니다.
- 실제 요청 수와 원장·알림의 수를 대조합니다.
로딩 아이콘에만 의존하지 말고 읽을 수 있는 상태 문구를 제공합니다. 버튼 폭이 바뀌어 화면이 크게 흔들리거나 고정 UI에 가려지는지도 봅니다. 테스트는 모의 응답으로 반복하고 실제 알림 시험은 정해진 범위에서 수행합니다.
완료 기준
사용자가 현재 상태를 이해하고 같은 요청을 불필요하게 반복하지 않아야 합니다. UI가 중복을 줄여도 외부 재전송까지 완벽히 한 번만 처리한다고 보장하지 않습니다. 처리 중 상태·서버 중복 정책·실패 안내가 함께 검수된 증거를 남깁니다. 완료율은 실제 접수 기준으로 별도 관찰하고 클릭 수 감소를 성과 악화로 오해하지 않습니다.
자주 묻는 질문
- 버튼만 disabled로 바꾸면 충분한가요?
- 다른 제출 경로와 서버 재시도는 남을 수 있습니다. UI 중복 방지와 실제 요청의 중복 처리 정책을 나눠 검수하고 실패 뒤 다시 시도할 수 있는지도 확인합니다.
- 오래 걸리면 계속 처리 중이라고만 보여줘도 되나요?
- 결과를 모르는 상태에서 사용자가 무엇을 해야 할지 안내가 필요합니다. 시간초과와 실제 처리 결과의 차이를 고려해 안전한 확인·재시도·대체 연락 경로를 정합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.