다단계 양식 UX: 진행 상태와 입력 내용 보존하기

여러 단계로 나눈 양식은 긴 요청을 끝내기 쉽게 만들어야 합니다. 화면만 나누고 입력한 내용을 잃을 기회를 늘려서는 안 됩니다. 사용자는 지금 어디에 있는지, 이전 단계로 돌아갈 수 있는지, 무엇이 저장됐는지, 제출 전 무엇이 남았는지 알아야 합니다. 여기서는 가상의 디자인팀이 ‘프로젝트 기본 정보 → 요구사항 → 선택 사항 → 검토’의 네 단계로 새 프로젝트를 요청한다고 가정합니다. Pixso 프로토타이핑에서 화면 이동을 연결하고, 실제 서비스가 구현해야 할 데이터 동작도 구분해 보겠습니다.

필드 개수가 아니라 사용자의 판단에 따라 단계를 나누기

사용자의 일이 바뀌는 지점에서 단계를 구분합니다. 이 사례에서는 기본 정보로 프로젝트를 식별하고, 요구사항으로 결과물을 설명하고, 선택 사항으로 추가 자료를 받으며, 검토 단계에서 제출 전 내용을 확인합니다. 한 필드만 있는 화면 다음에 관련 없는 질문 20개를 몰아넣으면 진행 점이 네 개여도 간단한 경험이 아닙니다.

시작할 때 필요한 정보와 흐름을 알려 줍니다. 예상 소요 시간을 표시한다면 근거가 있어야 하고, 담당자나 디자인 요청서처럼 준비할 자료를 명시합니다. 무엇을 해야 하는지도 알기 전에 가입이나 파일 업로드를 강요하지 않습니다. W3C의 여러 페이지 양식 지침도 논리적인 그룹화, 페이지마다 제공하는 안내, 선택 단계의 표시, 현재 위치 안내를 권합니다.

화면을 그리기 전에 필수 항목과 선택 단계, 저장 시점, 초안 보관 기간, 다른 팀원의 이어서 작성 가능 여부를 정합니다. 이는 서비스의 동작 규칙입니다. 진행 막대를 예쁘게 그렸다고 입력 내용이 저장되지는 않습니다.

현재 위치와 남은 일을 과장 없이 보여 주기

고정된 네 단계라면 설명 없는 막대보다 ‘요구사항 — 4단계 중 2단계’가 분명합니다. 현재 단계, 완료한 단계, 다음 단계의 이름을 표시합니다. 선택 단계를 건너뛸 수 있다면 75%라는 숫자는 실제 남은 작업량과 어긋날 수 있습니다. 정밀해 보이는 퍼센트보다 이름이 있는 순서 목록이 더 도움이 될 때가 많습니다.

제목, 진행 표시, 이동 버튼에서 같은 단계명을 씁니다. 검토 화면에서는 완료한 단계로 돌아가 수정할 수 있어야 합니다. 요구사항을 바꾸면서 뒤의 질문이 더는 필요 없어졌다면 어떤 답변이 제거되거나 재검토되는지 알리고, 조용히 지우지 않습니다. W3C도 이전 단계의 답변을 보관하면서 완료한 단계를 다시 확인할 수 있는 흐름을 설명합니다.

방문만 한 단계를 완료로 표시하지 마세요. 다음으로 가는 데 필요한 답변이 확인된 뒤에 완료로 표시하고, 아직 검증하지 않은 초안은 ‘작성 중’으로 구분합니다. 진행 표시는 위치를 알려 줄 뿐, 제출 성공을 보증하지 않습니다.

뒤로 가기, 건너뛰기, 다시 시작하기 전에 답변 보존하기

‘뒤로’의 규칙을 일관되게 만듭니다. 이전 단계로 가도 입력한 값은 그대로 있어야 합니다. 다음 단계로 이동할 때 저장한다면 서버가 성공을 확인한 뒤에만 ‘저장됨’을 보여 줍니다. 아직 통신 중인데 저장됐다고 표시해서는 안 됩니다. 자동 저장을 쓰더라도 ‘저장 중’, ‘저장됨’, ‘저장 실패’를 사용자가 구분할 수 있어야 합니다.

선택 사항을 건너뛰어도 앞에서 입력한 답변은 남아야 합니다. 검토 화면에는 추가 자료가 ‘제공되지 않음’으로 보이게 하고, 마지막 제출 순간에 갑자기 필수 오류를 내지 않습니다. 이 사례에서 요청서는 나중에 추가할 수 있지만 프로젝트 담당자는 필요하다고 정했다면, 화면과 서버 검증에 같은 규칙을 적용합니다.

연결이 끊긴 뒤 돌아왔을 때 서버에 저장된 초안과 기기에만 남은 미저장 편집을 구분합니다. 오프라인에서 바꾼 값이 서버에 반영된 것처럼 보이면 안 됩니다. 로그인 세션이 만료됐을 때의 복구는 별도의 문제입니다. 여기서는 정상적인 작성 과정에서 돌아가고 수정하는 흐름에 집중합니다.

오류를 고칠 수 있게 알리고 다른 답변은 지우지 않기

오류는 해당 필드 가까이에 두고 해결 방법을 구체적으로 설명합니다. ‘프로젝트 담당자를 입력하세요’는 행동으로 이어지지만 ‘문제가 발생했습니다’는 그렇지 않습니다. 첫 단계에서 알 수 있는 오류를 최종 검토까지 숨기지 않되, 사용자가 필드 입력을 마치기도 전에 매 글자 경고를 내보내지는 않습니다.

프로젝트 시작일보다 이른 납기일을 골랐다면 두 날짜를 유지하고 어떤 관계가 잘못됐는지 말합니다. 날짜를 고친 뒤에는 다른 유효한 답변을 그대로 둡니다. 브라우저에서 빠르게 확인하면 좋지만 최종 제출은 서버에서도 검증해야 합니다. W3C의 양식 검증 지침은 클라이언트 검사만으로 보안이나 최종 검증을 보장할 수 없다고 설명합니다.

다른 단계에 오류가 있으면 검토 화면에서 그 단계와 필드로 이동시키고, 나머지 답변은 보관한 채 수정 후 다시 검토로 돌아오게 합니다. 오류가 여러 개라면 요약 목록도 유용합니다. 브라우저에서는 통과한 값이 서버에서 거부됐다면 새 이유를 밝히고 초안 전체를 유지합니다. 빈 첫 화면부터 다시 입력하게 해서는 안 됩니다.

검토, 제출 중, 제출 결과를 서로 다른 상태로 다루기

검토 화면은 입력할 때 쓴 말과 같은 용어로 답변을 요약하고, 구역마다 ‘수정’ 동작을 제공합니다. 선택 사항이 비어 있다면 ‘제공되지 않음’이라고 보여 주지 필수인 것처럼 꾸미지 않습니다. 이전 답변을 바꿔 요청의 의미가 달라졌다면 제출 전에 요약도 갱신합니다.

‘제출’ 버튼을 누른 것과 요청이 접수된 것은 다릅니다. 처리 중에는 우발적인 중복 제출을 막고 실제 대기 상태를 보여 줍니다. 성공하면 다시 찾을 수 있는 요청 번호나 확인 화면, 다음 행동을 제공합니다. 오류가 나면 완성한 양식을 유지하고 요청이 접수됐는지를 설명합니다. 네트워크 시간 초과는 결과가 불분명할 수 있으므로, 먼저 기존 요청을 확인하지 않고 재제출을 권하지 않습니다.

화면 수보다 사용자가 작업을 완성하고 수정할 수 있는지를 평가합니다. 현재 단계의 이름을 말할 수 있는지, 돌아가서 답 하나만 고칠 수 있는지, 선택 단계를 건너뛸 수 있는지, 오류를 해결할 수 있는지, 최종 접수 여부를 판단할 수 있는지 확인합니다.

Pixso에서 이동 경로와 접근 가능한 상태 검토하기

Pixso 디자인 파일에 네 단계를 나란히 놓고 ‘다음’, ‘뒤로’, ‘건너뛰기’, ‘수정’을 연결합니다. 저장 중, 저장 실패, 필드 오류, 제출 중, 성공, 결과 불확실성도 별도 상태로 만듭니다. 모든 화면에서 같은 프로젝트 이름과 답변을 사용해야 뒤로 갔다 올 때 값이 보존되는지 확인할 수 있습니다. 보기 좋은 정상 경로만으로는 초안이 사라지는 문제를 찾기 어렵습니다.

동료에게 설명 없이 프로토타입을 사용해 보라고 합니다. 무엇이 저장됐는지 알 수 있을까요? 납기일만 수정하고 돌아와도 요청서를 다시 입력하지 않아도 될까요? 저장 실패와 최종 제출 실패를 구분할 수 있을까요? 막히는 지점의 문구와 이동을 고친 뒤 실제 저장, 검증, 요청 상태 규칙과 함께 개발팀에 전달합니다. Pixso는 이 상호작용을 설계하고 검토하는 데 쓰이며, 실제 양식의 데이터 보존은 서비스가 구현하고 검증해야 합니다. Pixso에서 양식 상태 설계하기.