삭제 확인 UX: 실행 취소와 확인 화면을 선택하는 기준

삭제 확인 화면은 사용자를 한 번 더 멈추게 하려고 만드는 것이 아닙니다. 무엇이 사라지고 다시 되돌릴 수 있는지를 실행 전에 알리기 위한 것입니다. 복구 가능한 개인 초안이라면 삭제 직후 ‘실행 취소’를 제공하는 편이 흐름을 덜 끊습니다. 반면 다른 사람의 작업이 들어 있는 공유 프로젝트를 삭제할 때는 대상과 영향을 먼저 검토해야 합니다. 이 글에서는 가상의 디자인 팀을 예로 두 상황을 설계하고 Pixso 프로토타이핑에서 흐름을 검토하는 방법까지 살펴봅니다.

빨간 버튼보다 삭제 대상을 먼저 정의하기

예시 작업 공간에는 Maya가 만든 ‘Autumn launch’라는 개인 초안 보드와, 이름은 같지만 디자인 파일 6개를 담은 공유 프로젝트가 있습니다. 이름이 같다고 삭제 결과까지 같지는 않습니다. 초안은 Maya만 사용하며 복구 가능한 휴지통으로 이동합니다. 공유 프로젝트에는 팀원 8명이 참여하고 있어 삭제되면 평소 사용하던 접근 경로가 사라집니다. 대화상자를 그리기 전에 무엇을 지우는지, 연관된 항목은 무엇인지, 누가 영향을 받는지부터 적어야 합니다.

작업 규칙을 ‘개인 초안을 30일 동안 휴지통으로 이동’과 ‘공유 프로젝트와 파일 6개를 삭제하고 구성원의 접근을 중단’처럼 구분해 씁니다. 30일은 이 가상 사례의 규칙이며 Pixso의 보관 정책을 뜻하지 않습니다. 실제 서비스에서 복구할 방법이 없다면 익숙한 패턴이라는 이유만으로 ‘실행 취소’를 넣어서는 안 됩니다.

안내와 권한도 구별해야 합니다. 경고는 결과를 알려 주지만 삭제 권한을 부여하지는 않습니다. 여기서는 소유자에게 이미 권한이 있다고 가정하고, 그 사람이 충분한 정보를 바탕으로 결정할 수 있는지에 집중합니다.

영향에 따라 실행 취소, 확인, 사전 검토 중 선택하기

큰 실수를 막을 수 있다면 흐름을 가장 덜 방해하는 방식을 선택합니다. 확실히 되돌릴 수 있는 작업은 즉시 처리하고 찾기 쉬운 실행 취소 경로를 제공할 수 있습니다. 되돌리기 어려운 작업은 확정 전에 결과를 보여 주어야 합니다. 사소한 작업마다 모달을 띄우면 내용을 읽지 않고 닫는 습관만 생길 수 있습니다.

프로젝트 이름을 다시 입력하게 하는 절차가 모든 위험 작업의 정답은 아닙니다. 복구할 수 없고 많은 파일이나 사람에게 영향을 준다면 고려할 수 있지만, 입력 역시 기계적으로 끝낼 수 있습니다. 먼저 정확한 범위와 결과를 보여 주고 최종 버튼에는 구체적인 동사를 사용합니다. 추가 입력은 실제 위험과 사용성 검증 결과가 뒷받침할 때만 넣습니다. 개인 초안의 실행 취소는 1초 만에 사라지는 토스트에만 숨기지 않습니다.

무엇을, 누구에게, 이후에 어떻게 되는지 설명하기

‘정말 삭제하시겠습니까?’라는 문장만으로는 사용자가 판단 근거를 직접 찾아야 합니다. 공유 프로젝트라면 ‘공유 프로젝트 Autumn launch를 삭제할까요?’라고 대상을 밝히고 ‘디자인 파일 6개를 프로젝트 구성원 8명이 더 이상 사용할 수 없습니다’라고 결과를 이어 씁니다. 정해진 기간 동안 복구할 수 있다면 누가 어디에서 복구할 수 있는지도 알려 줍니다. 실제 백엔드에 복구 경로가 없을 때만 ‘영구 삭제’라고 적습니다. 버튼은 ‘프로젝트 삭제’와 ‘프로젝트 유지’처럼 각각의 결과가 드러나게 합니다.

프로젝트 이름, 소유 관계, 영향받는 파일 수와 구성원에 대한 영향을 함께 보여 줍니다. 수치는 현재 데이터에서 가져오고 대화상자가 열린 사이 내용이 바뀌었다면 갱신해야 합니다. 확정 시점에 틀린 수를 보여 주는 것은 수를 표시하지 않는 것보다 나쁩니다. 파일이 아주 많다면 모달에 목록을 길게 쏟아 넣기보다 수와 범위를 확인할 수 있는 경로를 제공합니다.

강한 경고 색은 최종 작업과 핵심 결과를 나타낼 때만 사용합니다. 안전한 선택지도 쉽게 찾을 수 있어야 합니다. 색만으로 차이를 전달할 수 없으므로 두 버튼 모두 의미가 분명한 동사를 사용합니다.

성공뿐 아니라 결과가 불확실한 상태도 설계하기

삭제 버튼을 눌렀다고 흐름이 끝나지는 않습니다. 개인 초안은 휴지통으로 옮겨졌음을 알리고 실행 취소와 나중에 휴지통을 찾을 수 있는 안정적인 경로를 제공합니다. 복구에 성공하면 이전 위치로 되돌린 뒤 결과를 알립니다. 그 사이 초안이 변경되었다면 최신 내용을 조용히 덮어쓰지 말고 충돌을 설명해야 합니다.

공유 프로젝트는 요청이 진행되는 동안 중복 제출을 막습니다. 성공하면 소유자를 적절한 상위 화면으로 이동시키고 일반 탐색 메뉴에서 삭제된 프로젝트를 제거합니다. 다른 구성원에게 알리는 방식은 실제 서비스의 알림 정책을 따릅니다. 요청이 실패했다면 프로젝트와 확인 대화상자의 맥락을 유지해 다시 시도할지 판단하게 합니다. 네트워크 시간 초과는 특히 애매합니다. 응답은 없지만 삭제는 성공했을 수 있으므로 위험한 요청을 다시 보내기 전에 프로젝트나 요청 상태를 확인합니다.

다른 팀원이 열어 둔 파일의 처리 방식도 결정해야 합니다. 제품 구조에 따라 읽기 전용으로 바뀌거나, 파일이 닫히거나, 제거 안내가 표시될 수 있습니다. 실제 서비스 계약에 없는 이메일 발송이나 로컬 복사본 삭제를 약속해서는 안 됩니다.

마우스 없이도 이해할 수 있게 만들기

모달에는 보이는 제목, 읽을 수 있는 결과 설명, 접근 가능한 버튼, 분명한 포커스 표시, 예측할 수 있는 복귀 경로가 필요합니다. W3C 모달 대화상자 지침은 되돌리기 어려운 마지막 단계에서 가장 덜 파괴적인 선택지에 초기 포커스를 둘 수 있다고 설명합니다. 경고 대화상자 지침은 확인 메시지와 대화상자의 이름을 연결하는 방법을 다룹니다. 이런 지침을 닮은 이미지 자체가 접근성을 보장하지는 않습니다.

Escape 키와 닫기 버튼은 삭제를 실행하는 대신 보류 중인 결정을 취소해야 합니다. 대화상자를 닫으면 보통 시작 버튼으로 포커스를 돌립니다. 성공 후 버튼이 사라진다면 프로젝트 목록 제목처럼 의미 있는 위치로 옮깁니다. 네트워크 요청 중인 상태도 알리고 반응하지 않는 화면에 사용자를 무기한 가두지 않습니다.

Pixso에서 두 흐름을 나란히 검토하기

Pixso 캔버스에 개인 초안과 공유 프로젝트의 삭제 흐름을 나란히 놓습니다. 초안의 ‘삭제’를 ‘휴지통으로 이동’, ‘실행 취소’, ‘복구 완료’ 화면에 연결합니다. 공유 프로젝트의 ‘삭제’는 ‘범위 검토’, ‘요청 중’, ‘성공 후 화면’, ‘오류 복구’로 연결합니다. 두 흐름에서 같은 프로젝트 이름을 쓰고 파일 수와 구성원 수가 앞뒤로 일치하는지 확인합니다. 확인 화면이 보기 좋아도 다음 상태가 경고 내용과 모순되면 충분하지 않습니다.

검토자에게 세 가지를 물어봅니다. ‘어느 Autumn launch를 지우는가?’, ‘누가 접근을 잃는가?’, ‘실수라면 무엇을 할 수 있는가?’ 답을 추측해야 한다면 대상 이름, 결과 설명 또는 복구 화면을 다시 설계합니다. 개발자에게는 실제 보관 기간, 권한, 알림, 요청 상태 규칙과 함께 흐름을 전달합니다. Pixso는 상호작용을 설계하고 검토하는 데 도움을 주지만 운영 환경의 삭제를 실행하거나 백엔드의 복구 정책을 보장하지는 않습니다. Pixso에서 두 흐름 검토하기.