업로드 파일 교체 UX: 검토 맥락을 잃지 않는 흐름

제출 후 파일 교체는 업로드 재시도와 다릅니다. 새 파일이 맞더라도 검토자가 댓글, 승인 맥락과 수정 근거를 잃을 수 있습니다. Pixso UI 디자인 메이커에서 기존 파일, 확인 화면과 완료 상태를 함께 프로토타이핑하세요.

이 글은 예산 표를 수정하는 가상의 프로젝트 계획 PDF를 따라 제출 기록과 검토 요청을 보존하는 흐름을 설명합니다.

승인된 기록에서 시작하기

보통 업로드 화면은 빈 상태에서 시작하지만 여기서는 제출이 이미 존재합니다. Project_Plan_v1.pdf가 검토 중이고 6장의 예산 표를 수정해 달라는 요청을 받은 상황입니다.

작성자가 새 파일을 고르기 전에 현재 파일명, 상태와 검토자의 요청을 보여 주세요. 실제 활성 첨부파일을 바꿀 때만 “현재 파일 교체”라는 구체적인 라벨을 사용합니다.

확정 전에 비교하기

확인 단계는 현재 활성 파일, 활성화될 파일, 이전 버전과 검토 스레드에 생기는 일을 답해야 합니다. 두 이름과 변경 요약을 나란히 보여 주세요.

안전한 기본값은 교체가 성공할 때까지 이전 승인 파일을 활성 상태로 유지하는 것입니다. 대화상자를 닫거나 연결이 끊겨도 원래 제출을 찾을 수 있어야 합니다.

검토 요청을 제출 기록에 연결하기

“6장”에 대한 댓글은 첫 PDF의 바이트가 아니라 검토한 작업에 대한 것입니다. 교체 후에도 같은 제출, 요청 ID와 수정 파일을 연결해 주세요.

페이지 배치가 실제로 검증되지 않았다면 이전 PDF의 좌표를 새 PDF에 그대로 표시하지 마세요. 페이지 순서나 레이아웃이 바뀌었을 수 있으므로 이전 버전의 댓글임을 표시하고 새 위치 확인을 요청하는 편이 안전합니다.

교체 중 검토가 계속될 때

검토자가 이전 파일을 읽는 동안 작성자가 새 파일을 고를 수 있습니다. 열린 검토 세션에서 문서를 조용히 바꾸지 말고, 검토 완료를 기다리거나 새 버전을 별도 상태로 표시하는 정책을 정하세요.

예를 들어 검토자가 10:02에 이전 PDF를 열고 작성자가 10:04에 교체했다면 6장 댓글은 실제로 본 버전에 남아야 합니다.

실패와 취소를 분명하게

전송 전에 형식, 빈 파일과 용량 한도를 검사합니다. 전송 중 진행률은 전송 상태만 설명하며 교체 완료를 증명하지 않습니다.

78%에서 네트워크가 끊기면 원래 파일이 여전히 활성이라고 알리고 안전한 재시도를 제공합니다. 업로드 후 PDF가 거부되면 이유를 설명하고 기존 제출을 잃지 않은 채 다른 파일을 선택하게 합니다.

GOV.UK 파일 업로드 지침의 구체적인 오류 문구와 여정 안에서 이전 파일을 재사용하는 원칙을 참고하되 보안과 개인정보 조건을 확인하세요.

시각 사용자와 스크린 리더에 상태 전달

“검토 중”에서 “교체 완료”로 바뀌는 상태는 색상만으로 전달하지 말고 텍스트와 적절한 알림으로 표시하세요. 포커스를 갑자기 이동시키지 않습니다.

키보드 사용자는 교체를 열고 두 파일명을 확인하고 취소·확정한 뒤 제출 기록의 합리적인 위치로 돌아올 수 있어야 합니다. 열린 댓글이 있었다면 새 버전과 이전 댓글로 돌아가는 경로를 보존하세요.

Pixso에서 결정 경로 프로토타이핑

Pixso에 검토 요청이 붙은 승인 파일, 두 버전 확인 화면, 교체 완료 상태를 세 화면으로 배치하세요. 실패, 취소, 연결 끊김과 검토 중 상태도 추가합니다.

검토자에게 “이전 댓글은 어디에 있나요?”라고 묻게 하고 작성자에게 “전송이 실패하면 검토자는 어떤 파일을 보나요?”라고 물어 보세요. 답이 추측에 의존하면 흐름을 수정해야 합니다.

결론

파일 교체 UX는 새 파일을 받는 기능이 아니라 버전, 검토 근거와 실패 복구를 보존하는 기록 흐름입니다. 이전 파일을 안전한 기본값으로 유지하고 명확한 비교·상태·댓글 연결을 제공하세요.