정상·로딩·빈 상태·오류 화면

한 장의 정상 화면으로는 복구 행동이 보이지 않습니다

신청 화면 초안에 행사 선택과 제출 버튼만 그렸습니다. 성공했을 때는 그럴듯하지만 목록이 비거나 요청이 멈추면 사용자는 무엇을 할지 알 수 없습니다. 특히 Q01의 결과 경로 문제는 접수 문구를 보여 주는 순간보다 그 이후 어디로 가는지에서 드러납니다. 이번 레슨은 동일한 화면이 어떤 상태로 바뀌고 어떤 행동을 제공하는지 표로 만듭니다. 색과 배치를 정교하게 꾸미기 전에 정보·문구·복귀 위치를 정합니다.

업무 상태와 화면 상태를 다른 축으로 둡니다

PENDING·APPROVED·REJECTED는 신청의 업무 상태입니다. loading·empty·permission-denied는 데이터를 가져오거나 표시하는 화면 상태입니다. 승인 대기 신청을 조회하는 중에도 화면은 로딩일 수 있습니다. 요청이 실패했다는 이유로 신청을 REJECTED로 바꾸면 통신 문제를 행사 반려로 오해하게 합니다. 화면 표에는 업무 상태와 표시 상태를 별도 칸에 적고 실패 시 기존 상태를 최신값처럼 확정하지 않습니다.

텍스트 초안은 제목, 표시 정보, 안내, 다음 행동, 입력 보존, 포커스 위치 여섯 항목으로 작성합니다. 정상 접수 초안에는 “신청 접수 · 승인 대기”, 행사 EV01, 신청 A001, “신청 내역 확인”을 둡니다. 내부 소유자 번호나 전화번호는 표시 정보에 넣지 않습니다. m04 fields의 생성 주체와 열람 범위를 읽어 사용자가 입력할 수 있는 행사 선택과 서버가 반환하는 신청 ID·상태를 구별합니다.

로딩과 빈 상태의 판단 근거를 씁니다

로딩은 조회를 요청했지만 아직 결과를 확인하지 못한 상태입니다. “신청 내역을 불러오는 중입니다”를 표시하고 현재 조회 버튼의 포커스를 갑자기 다른 위치로 옮기지 않는 초안을 만듭니다. 취소를 제공한다면 조회 대기만 끝내는 행동으로 설명하며 이미 저장된 신청을 취소한다고 말하지 않습니다. 늦게 도착한 응답이 취소 이후 다른 계정 화면을 덮지 않도록 처리할 조건은 개발자 검토 항목에 둡니다.

빈 상태는 본인 내역 조회가 성공했고 목록 길이가 0이라는 근거가 있어야 합니다. “아직 신청 내역이 없습니다”와 “행사 목록 보기”를 함께 씁니다. 조회 오류를 빈 배열로 대체하고 같은 문구를 띄우면 사용자가 신청을 다시 생성할 수 있습니다. 신청 번호 하나를 조회한 NOT_FOUND 응답과 본인 목록 전체가 빈 경우도 다릅니다. 이번 빈 목록은 새 화면 제안이며 기존 모의 API가 목록 조회를 구현했다고 쓰지 않습니다.

오류 문구는 다음 행동을 설명합니다

행사 누락에는 “신청할 행사를 선택해 주세요”를 선택 입력 가까이에 두고 첫 오류 입력으로 포커스를 보낼 것을 제안합니다. 다른 정상 입력을 지우지 않습니다. 화면 색상만 붉게 만드는 초안은 어떤 값을 수정할지 알려 주지 못합니다. 입력의 이름과 오류 설명을 연결하는 구현은 더 읽기의 폼 장에서 확인하고 이 문서에서는 사용자에게 보이는 이름과 수정할 위치를 명시합니다.

권한 거부에는 “현재 계정으로 이 작업을 할 수 없습니다”와 본인 내역 이동을 둡니다. 다른 사람의 이름·신청 상태를 배경에 남겨 두지 않습니다. 만료 안내는 로그인 확인과 재로그인 후 최신 조회로 연결합니다. 두 상태 모두 아무 신청이나 보여 주는 대체 화면으로 복구하지 않습니다. 화면에서 버튼을 숨기는 것만으로 서버 권한 검사가 끝났다고 판단하지 않고 access-policy.json의 정책 사례를 함께 연결합니다.

저장 실패와 응답 유실을 다른 화면으로 만듭니다

m03 STORE_UNAVAILABLE 사례는 저장되지 않았다는 모의 응답이 확인되었습니다. 선택한 EV01과 재전송 키를 유지하고 같은 본문으로 재시도하는 초안을 만듭니다. “저장하지 못했습니다”라는 문구를 쓸 근거가 있는 경우입니다. 반면 응답을 받지 못했다면 실제 저장 여부는 미확인입니다. 이 화면에는 “응답을 확인하지 못했습니다. 접수 여부를 확인해 주세요”와 내역 확인 행동을 두어 새 신청 생성을 먼저 권하지 않습니다.

이 차이는 사용자 기분을 고려한 말투보다 더 중요한 정보입니다. 전자는 미저장 확인, 후자는 결과 불확실성입니다. 네트워크 오류에 정상 접수 화면을 보여 주거나 실패 화면에 “재시도하면 절대 중복되지 않습니다”라고 단정하지 않습니다. 서버가 같은 키와 본문을 처리한다는 계약을 확인할 담당자와 이후 조회를 남깁니다. 이번 텍스트 화면 자체가 네트워크 복구를 실행한 결과는 아닙니다.

중복 제출 화면은 기존 신청을 찾게 합니다

동일 키·동일 본문 재전송 응답은 A001을 다시 표시합니다. “이미 접수된 신청입니다 · 승인 대기”와 내역 확인을 제시하고 신규 신청 수가 늘지 않는 인수 기준으로 연결합니다. 재전송 응답을 무조건 에러로 표시하면 사용자가 다른 기기에서 새로 제출할 수 있습니다. 처리 중 버튼 비활성화는 빠른 반복을 줄이는 보조 설계로 적되 서버의 중복 처리와 구분합니다. 응답 확인 뒤에는 다음 행동 버튼을 다시 사용할 수 있도록 전환 조건을 씁니다.

키보드 경로를 상태마다 점검합니다

초안에 행사 선택→제출→내역 확인의 이동 순서를 적습니다. 키보드만 쓰는 사용자가 각 행동에 도달하고 실행할 수 있어야 하므로 Tab 이동과 Enter 실행을 검토 과업에 넣습니다. 오류 후 첫 문제 입력, 접수 성공 뒤 결과 제목, 재시도 화면의 버튼처럼 상태별 포커스 목적지를 적습니다. 이는 제품 설계 제안이며 브라우저·스크린리더에서 실제 동작을 확인한 접근성 판정은 아닙니다. 움직이는 UI를 만들 때 구현 담당자와 시험합니다.

포커스 이동은 모든 상태 변화 때 강제로 하는 동작이 아닙니다. 조회 중에 사용자 입력을 끊지 않도록 유지할 때도 있고 제출 오류를 발견하게 하려고 이동할 때도 있습니다. 변경 이유를 포커스 칸에 씁니다. 화면 제목으로 이동시키는 제안에는 그 제목이 키보드 포커스를 받을 수 있게 구현할 필요를 남깁니다. 폼이 사라지면서 포커스가 문서 시작으로 튀는 경우나 재시도 버튼이 계속 비활성화된 경우를 검토자가 찾아보게 합니다.

화면 카드가 서로 모순되지 않는지 봅니다

UI-empty에 행사 목록으로 이동한다고 적었는데 연결 시나리오 결과가 자동 재신청이라면 두 문서가 다릅니다. 화면 표의 nextAction은 인수 기준에도 그대로 연결합니다. visibleFields에는 허용된 응답 정보만 넣고 권한 거부·만료 화면에는 보호 데이터를 비웁니다. 입력 보존이라는 말도 구체화합니다. 자기 행사 선택은 유지할 수 있지만 다른 계정의 조회 결과는 재로그인 이후 계속 표시하지 않는다는 차이를 preserve에 적습니다.

동료 검토에서는 9종 화면 카드를 섞어 주고 각 카드에서 다음에 무엇을 해야 하는지 설명하게 합니다. “오류가 발생했습니다”만 보고 재로그인과 재시도를 구별하지 못하면 문구를 보완합니다. 출력 없는 문서 작성 단계에서는 완성 초안을 열어 항목을 눈으로 확인합니다. 디자인 리뷰의 성공을 실제 사용자 과업 성공률로 바꾸지 않습니다. 다음 레슨은 이 카드에서 표시 문구와 저장 증거를 골라 반복해서 확인할 인수 기준으로 작성합니다.