UX/UI
삭제 버튼을 누른 다음, 사용자는 돌아올 수 있나요?
삭제 버튼을 누른 다음, 사용자는 돌아올 수 있나요?
삭제 확인 창만으로는 사용자의 실수를 막기 어렵습니다. 보관과 휴지통, 영구 삭제를 구분하고 실행 취소부터 복구 이후의 상태까지 연결하는 UX 설계 기준을 살펴봅니다.
삭제 확인 창만으로는 사용자의 실수를 막기 어렵습니다. 보관과 휴지통, 영구 삭제를 구분하고 실행 취소부터 복구 이후의 상태까지 연결하는 UX 설계 기준을 살펴봅니다.
삭제 버튼보다 먼저, 무엇을 없앨지 정합니다
끝난 프로젝트를 목록에서 치우고 싶어 삭제 버튼을 눌렀습니다. 확인 창까지 읽고 실행했는데 잠시 뒤 팀원이 관련 파일을 찾습니다. 목록만 정리하려던 사람과 자료가 사라진 팀원이 서로 다른 결과를 예상한 것입니다.
삭제를 누르기 전에 한 번 더 물었다고 해서 이런 문제가 해결되지는 않습니다. 사용자가 없애려던 대상과 서비스가 실제로 없앤 대상이 달랐기 때문입니다. 버튼을 누르기 전에는 무엇이 바뀌는지, 누른 뒤에는 어디에서 되돌릴 수 있는지가 이어져야 합니다.
삭제 UX는 확인 창의 문구보다 데이터의 처리 방식을 먼저 정하는 작업입니다. 목록에서 숨기는 것인지, 사용을 중단하는 것인지, 저장된 자료까지 없애는 것인지 구분해야 화면도 분명해집니다.
이 글에서는 가상의 팀 프로젝트 서비스를 예로 들겠습니다. ‘여름 캠페인’ 프로젝트에는 일정, 작업 카드, 첨부파일이 있습니다. 팀은 종료된 프로젝트를 현재 작업 목록에서 정리하고 싶습니다. 이때 필요한 기능이 반드시 삭제인 것은 아닙니다.
사용자가 원하는 것은 정리일 수 있습니다
다음 두 요청은 비슷해 보이지만 처리 결과가 다릅니다.
“이번 주 목록에서는 안 보였으면 좋겠어요. 나중에 자료는 찾아야 해요.”
“잘못 만든 테스트 프로젝트예요. 첨부자료까지 모두 없애고 싶어요.”
첫 번째에는 보관이, 두 번째에는 삭제가 맞을 수 있습니다. 두 요청을 모두 휴지통 아이콘 하나로 해결하려고 하면 사용자가 결과를 추측해야 합니다. 기능 이름을 정하기 전에 실제로 남길 것과 없앨 것을 적어보세요.
행동 | 이 서비스에서 정한 결과 | 다시 찾는 곳 |
|---|---|---|
보관 | 현재 목록에서 제외하고 자료는 유지 | 보관함 |
휴지통으로 이동 | 일반 사용을 중단하고 복구 대상으로 유지 | 휴지통 |
영구 삭제 | 안내한 대상 자료를 복구할 수 없게 삭제 | 복구 불가 |
이 표는 가상 서비스의 정책 예시입니다. 보관이나 휴지통이라는 이름만 붙이면 자료가 자동으로 보존되는 것은 아닙니다. 실제 저장 방식과 복구 동작이 화면의 약속을 따라야 합니다.
확인 창에는 대상과 결과를 함께 보여줍니다
“정말 삭제하시겠습니까?”에는 빠진 정보가 많습니다
팀원이 ‘여름 캠페인’을 선택하고 삭제 메뉴를 열었다고 해보겠습니다. 확인 창에 다음 문장만 보이면 무엇을 판단할 수 있을까요?
정말 삭제하시겠습니까?
[취소] [확인]
이 문구에는 프로젝트 이름이 없습니다. 내 목록에서만 사라지는지, 팀 전체에서 사라지는지도 알 수 없습니다. 첨부파일이 함께 없어지는지도 설명하지 않습니다. 사용자가 확인을 눌렀다는 사실만으로 이런 결과까지 이해했다고 보기는 어렵습니다.
이 서비스가 프로젝트를 먼저 휴지통으로 옮기도록 설계했다면 화면에도 그 결과를 그대로 적습니다.
‘여름 캠페인’을 휴지통으로 이동할까요?
팀의 진행 중 목록에서 사라집니다. 작업과 첨부파일은 휴지통에서 함께 복구할 수 있습니다.
[프로젝트 유지] [휴지통으로 이동]
대상 이름, 영향을 받는 범위, 복구 방법을 읽고 선택할 수 있어야 합니다. ‘확인’을 ‘휴지통으로 이동’으로 바꾸는 것만으로 끝내지 않고 실제로 함께 이동하는 자료까지 맞춰야 합니다.
영구 삭제에는 다른 판단이 필요합니다
휴지통에 있는 프로젝트를 완전히 없앨 때는 같은 확인 창을 재사용하지 않습니다. 복구 가능한 이동과 복구할 수 없는 삭제는 결과가 다르기 때문입니다.
‘여름 캠페인’을 영구 삭제할까요?
이 프로젝트의 작업과 첨부파일이 삭제됩니다. 삭제한 자료는 이 서비스에서 복구할 수 없습니다.
[휴지통에 유지] [영구 삭제]
실제로 어떤 자료가 삭제되는지는 구현 범위를 확인해 작성해야 합니다. 공유 파일 원본은 남고 프로젝트 안 연결만 끊어진다면 ‘첨부파일이 삭제됩니다’라고 안내해서는 안 됩니다. 삭제 작업이 일정 시간 뒤에 처리된다면 즉시 사라진다고 표현하는 것도 맞지 않습니다.
GOV.UK 디자인 시스템은 쉽게 되돌릴 수 없는 심각한 파괴적 행동에 경고 버튼을 제한적으로 사용하고, 추가 확인 단계를 두도록 안내합니다. 모든 정리 작업을 같은 빨간 버튼으로 만들기보다 결과의 무게를 구분할 근거가 됩니다. GOV.UK 경고 버튼 지침
여러 개를 선택했다면 개수를 숨기지 않습니다
목록에서 프로젝트 세 개를 선택한 상황이라면 확인 창에도 ‘선택한 프로젝트 3개’라고 표시합니다. 선택 목록이 화면 밖에 있어도 현재 작업의 범위를 다시 확인할 수 있어야 합니다. 중요한 항목은 이름을 함께 보여주는 방법도 검토할 수 있습니다.
이 중 하나만 이동하지 못했을 때의 결과도 정해야 합니다. 두 개는 이동했고 하나가 남았다면 ‘완료’ 한마디로 끝내지 않습니다.
프로젝트 2개를 휴지통으로 이동했습니다. ‘겨울 캠페인’은 이동하지 못했습니다. 목록을 확인해 주세요.
이런 결과 안내는 부가 문구가 아닙니다. 사용자가 같은 작업을 다시 할지 결정하는 데 필요한 정보입니다.
실행 취소는 버튼이 아니라 복구 동작입니다
작은 실수를 바로 고칠 수 있게 합니다
프로젝트를 보관한 직후 잘못 선택했다는 사실을 알아차렸다면 화면 아래의 짧은 안내에서 바로 되돌릴 수 있게 할 수 있습니다.
‘여름 캠페인’을 보관했습니다. [실행 취소]
사용자는 보관함을 찾아 들어가지 않고도 방금 한 행동을 되돌립니다. Android 공식 문서도 보관 안내에 실행 취소 동작을 연결해 항목을 다시 꺼내는 예시를 설명합니다. 중요한 것은 안내를 지우는 버튼이 아니라 원래 상태로 돌리는 동작을 연결한다는 점입니다. Android 실행 취소 동작 예시
‘실행 취소’를 눌렀을 때 메시지만 사라지고 프로젝트는 계속 보관돼 있다면 복구 기능이 아닙니다. 목록, 상태, 접근 경로가 함께 돌아와야 합니다. 처리 중에는 중복으로 복구를 요청하지 않도록 하고 결과를 확인한 뒤 복구되었다고 알려줍니다.
잠깐 보이는 안내만 복구 경로로 삼지 않습니다
사용자는 다른 화면을 보거나 긴 프로젝트 이름을 읽다가 실행 취소 기회를 놓칠 수 있습니다. 그래서 이 서비스에서는 안내가 사라진 뒤에도 보관함에서 복원할 수 있게 정합니다.
보관함 → ‘여름 캠페인’ 선택 → [보관 해제]
휴지통도 마찬가지입니다. 삭제가 유예되는 기간을 정했다면 사용자가 복구할 수 있는 위치와 종료 시점을 알 수 있어야 합니다. 기간은 운영 정책에 맞게 정하되 다른 서비스가 쓴 일수를 이유 없이 가져오지 않습니다.
실행 취소 안내의 노출 시간과 자료의 복구 가능 기간은 서로 다른 규칙입니다. 안내가 사라졌다고 곧바로 자료가 영구 삭제되는지, 별도 휴지통에서 계속 복원할 수 있는지 팀이 같은 답을 갖고 있어야 합니다.
복구가 실패한 상황도 화면에 남깁니다
복구를 요청했지만 서버에서 결과를 받지 못했다면 ‘복구되었습니다’라고 먼저 안내하지 않습니다. 원래 목록에 임시로 보여주더라도 실제 복원 여부를 확인하지 않은 상태와 완료 상태를 구분해야 합니다.
복구 결과를 확인하지 못했습니다. 보관함에서 현재 상태를 확인해 주세요.
복원할 때 무엇이 돌아오는지도 정합니다. 프로젝트 이름만 복구되고 작업이나 파일 연결은 돌아오지 않는다면 사용자는 원래 상태로 돌아왔다고 느끼기 어렵습니다. 함께 복원할 자료를 처음부터 한 묶음으로 정의해야 하는 이유입니다.
이름이 같은 새 프로젝트가 생겼거나 원래 위치가 없어졌을 때도 판단이 필요합니다. 사용자가 다시 이름을 붙여야 하는지, 다른 위치를 고르게 할지, 별도의 복구 위치에 보관할지 정합니다. 복구 버튼을 제공한다는 것은 이런 상황에서 자료를 어디로 돌려놓을지도 약속하는 일입니다.
삭제와 복구를 한 번의 흐름으로 점검합니다
삭제 기능을 검토할 때 확인 창만 캡처해두면 이후의 문제를 놓치기 쉽습니다. 대상 선택부터 결과 안내, 복구까지 연결해서 확인해보세요. 가상 서비스의 ‘여름 캠페인’을 기준으로 하면 다음 순서로 점검할 수 있습니다.
정리 목적을 확인합니다. 현재 목록에서 치우려는 것인지, 자료까지 없애려는 것인지 나눕니다. 보관으로 충분한 상황에 삭제를 먼저 제시하고 있지 않은지 봅니다.
대상과 범위를 읽습니다. 프로젝트 이름과 선택 개수가 맞는지, 내 화면과 팀 전체 중 어디에 영향을 주는지 확인합니다.
결과를 실제로 확인합니다. 목록에서 사라진 뒤 보관함이나 휴지통에서 찾습니다. 작업과 첨부자료도 안내한 방식으로 남아 있는지 확인합니다.
복구한 뒤 다시 사용합니다. 실행 취소와 보관함 복원 모두 시도합니다. 프로젝트를 열고 작업과 파일에 다시 접근할 수 있는지 확인합니다.
끝나지 않은 처리를 구분합니다. 일부 항목만 성공하거나 복구 결과가 불확실할 때 성공 메시지로 덮이지 않는지 봅니다.
기획서에는 화면보다 약속을 먼저 남깁니다
디자인과 개발에 전달할 내용을 길게 쓸 필요는 없습니다. 다음 질문에 같은 답을 할 수 있으면 시작할 수 있습니다.
보관과 삭제는 각각 무엇을 바꾸나요?
다른 팀원이 보고 있던 자료에도 영향을 주나요?
어떤 항목을 함께 복원하나요?
실행 취소 안내가 사라지면 어디에서 복구하나요?
되돌릴 수 없는 시점은 언제이며, 사용자에게 어떻게 알려주나요?
이 답이 빠져 있으면 디자이너는 복구 버튼을 그렸는데 개발 범위에는 복구할 데이터가 없는 상황이 생길 수 있습니다. 반대로 서버에는 복구할 자료가 남아 있어도 화면에 찾는 경로가 없으면 사용자는 이미 잃어버린 것으로 받아들일 수 있습니다.
좋은 삭제 경험은 사용자가 결과를 예상하고 가능한 실수는 바로잡을 수 있는 경험입니다. 모든 행동을 여러 번 확인시키는 방식보다, 정리 목적에 맞는 기능을 제공하고 약속한 복구 경로를 실제로 연결하는 일이 먼저입니다.
4PS는 서비스 화면을 설계할 때 버튼과 확인 창뿐 아니라 실행 이후의 상태와 복구 범위까지 함께 정리합니다. 삭제·보관·숨김이 섞여 운영 문의가 반복된다면 현재 화면과 처리 규칙을 알려주세요. 사용자가 기대하는 결과와 실제 동작이 어디에서 달라지는지부터 함께 살펴보겠습니다.
Latest Blogs
UX/UI
삭제 버튼을 누른 다음, 사용자는 돌아올 수 있나요?
삭제 버튼을 누른 다음, 사용자는 돌아올 수 있나요?
삭제 확인 창만으로는 사용자의 실수를 막기 어렵습니다. 보관과 휴지통, 영구 삭제를 구분하고 실행 취소부터 복구 이후의 상태까지 연결하는 UX 설계 기준을 살펴봅니다.
삭제 확인 창만으로는 사용자의 실수를 막기 어렵습니다. 보관과 휴지통, 영구 삭제를 구분하고 실행 취소부터 복구 이후의 상태까지 연결하는 UX 설계 기준을 살펴봅니다.
삭제 버튼보다 먼저, 무엇을 없앨지 정합니다
끝난 프로젝트를 목록에서 치우고 싶어 삭제 버튼을 눌렀습니다. 확인 창까지 읽고 실행했는데 잠시 뒤 팀원이 관련 파일을 찾습니다. 목록만 정리하려던 사람과 자료가 사라진 팀원이 서로 다른 결과를 예상한 것입니다.
삭제를 누르기 전에 한 번 더 물었다고 해서 이런 문제가 해결되지는 않습니다. 사용자가 없애려던 대상과 서비스가 실제로 없앤 대상이 달랐기 때문입니다. 버튼을 누르기 전에는 무엇이 바뀌는지, 누른 뒤에는 어디에서 되돌릴 수 있는지가 이어져야 합니다.
삭제 UX는 확인 창의 문구보다 데이터의 처리 방식을 먼저 정하는 작업입니다. 목록에서 숨기는 것인지, 사용을 중단하는 것인지, 저장된 자료까지 없애는 것인지 구분해야 화면도 분명해집니다.
이 글에서는 가상의 팀 프로젝트 서비스를 예로 들겠습니다. ‘여름 캠페인’ 프로젝트에는 일정, 작업 카드, 첨부파일이 있습니다. 팀은 종료된 프로젝트를 현재 작업 목록에서 정리하고 싶습니다. 이때 필요한 기능이 반드시 삭제인 것은 아닙니다.
사용자가 원하는 것은 정리일 수 있습니다
다음 두 요청은 비슷해 보이지만 처리 결과가 다릅니다.
“이번 주 목록에서는 안 보였으면 좋겠어요. 나중에 자료는 찾아야 해요.”
“잘못 만든 테스트 프로젝트예요. 첨부자료까지 모두 없애고 싶어요.”
첫 번째에는 보관이, 두 번째에는 삭제가 맞을 수 있습니다. 두 요청을 모두 휴지통 아이콘 하나로 해결하려고 하면 사용자가 결과를 추측해야 합니다. 기능 이름을 정하기 전에 실제로 남길 것과 없앨 것을 적어보세요.
행동 | 이 서비스에서 정한 결과 | 다시 찾는 곳 |
|---|---|---|
보관 | 현재 목록에서 제외하고 자료는 유지 | 보관함 |
휴지통으로 이동 | 일반 사용을 중단하고 복구 대상으로 유지 | 휴지통 |
영구 삭제 | 안내한 대상 자료를 복구할 수 없게 삭제 | 복구 불가 |
이 표는 가상 서비스의 정책 예시입니다. 보관이나 휴지통이라는 이름만 붙이면 자료가 자동으로 보존되는 것은 아닙니다. 실제 저장 방식과 복구 동작이 화면의 약속을 따라야 합니다.
확인 창에는 대상과 결과를 함께 보여줍니다
“정말 삭제하시겠습니까?”에는 빠진 정보가 많습니다
팀원이 ‘여름 캠페인’을 선택하고 삭제 메뉴를 열었다고 해보겠습니다. 확인 창에 다음 문장만 보이면 무엇을 판단할 수 있을까요?
정말 삭제하시겠습니까?
[취소] [확인]
이 문구에는 프로젝트 이름이 없습니다. 내 목록에서만 사라지는지, 팀 전체에서 사라지는지도 알 수 없습니다. 첨부파일이 함께 없어지는지도 설명하지 않습니다. 사용자가 확인을 눌렀다는 사실만으로 이런 결과까지 이해했다고 보기는 어렵습니다.
이 서비스가 프로젝트를 먼저 휴지통으로 옮기도록 설계했다면 화면에도 그 결과를 그대로 적습니다.
‘여름 캠페인’을 휴지통으로 이동할까요?
팀의 진행 중 목록에서 사라집니다. 작업과 첨부파일은 휴지통에서 함께 복구할 수 있습니다.
[프로젝트 유지] [휴지통으로 이동]
대상 이름, 영향을 받는 범위, 복구 방법을 읽고 선택할 수 있어야 합니다. ‘확인’을 ‘휴지통으로 이동’으로 바꾸는 것만으로 끝내지 않고 실제로 함께 이동하는 자료까지 맞춰야 합니다.
영구 삭제에는 다른 판단이 필요합니다
휴지통에 있는 프로젝트를 완전히 없앨 때는 같은 확인 창을 재사용하지 않습니다. 복구 가능한 이동과 복구할 수 없는 삭제는 결과가 다르기 때문입니다.
‘여름 캠페인’을 영구 삭제할까요?
이 프로젝트의 작업과 첨부파일이 삭제됩니다. 삭제한 자료는 이 서비스에서 복구할 수 없습니다.
[휴지통에 유지] [영구 삭제]
실제로 어떤 자료가 삭제되는지는 구현 범위를 확인해 작성해야 합니다. 공유 파일 원본은 남고 프로젝트 안 연결만 끊어진다면 ‘첨부파일이 삭제됩니다’라고 안내해서는 안 됩니다. 삭제 작업이 일정 시간 뒤에 처리된다면 즉시 사라진다고 표현하는 것도 맞지 않습니다.
GOV.UK 디자인 시스템은 쉽게 되돌릴 수 없는 심각한 파괴적 행동에 경고 버튼을 제한적으로 사용하고, 추가 확인 단계를 두도록 안내합니다. 모든 정리 작업을 같은 빨간 버튼으로 만들기보다 결과의 무게를 구분할 근거가 됩니다. GOV.UK 경고 버튼 지침
여러 개를 선택했다면 개수를 숨기지 않습니다
목록에서 프로젝트 세 개를 선택한 상황이라면 확인 창에도 ‘선택한 프로젝트 3개’라고 표시합니다. 선택 목록이 화면 밖에 있어도 현재 작업의 범위를 다시 확인할 수 있어야 합니다. 중요한 항목은 이름을 함께 보여주는 방법도 검토할 수 있습니다.
이 중 하나만 이동하지 못했을 때의 결과도 정해야 합니다. 두 개는 이동했고 하나가 남았다면 ‘완료’ 한마디로 끝내지 않습니다.
프로젝트 2개를 휴지통으로 이동했습니다. ‘겨울 캠페인’은 이동하지 못했습니다. 목록을 확인해 주세요.
이런 결과 안내는 부가 문구가 아닙니다. 사용자가 같은 작업을 다시 할지 결정하는 데 필요한 정보입니다.
실행 취소는 버튼이 아니라 복구 동작입니다
작은 실수를 바로 고칠 수 있게 합니다
프로젝트를 보관한 직후 잘못 선택했다는 사실을 알아차렸다면 화면 아래의 짧은 안내에서 바로 되돌릴 수 있게 할 수 있습니다.
‘여름 캠페인’을 보관했습니다. [실행 취소]
사용자는 보관함을 찾아 들어가지 않고도 방금 한 행동을 되돌립니다. Android 공식 문서도 보관 안내에 실행 취소 동작을 연결해 항목을 다시 꺼내는 예시를 설명합니다. 중요한 것은 안내를 지우는 버튼이 아니라 원래 상태로 돌리는 동작을 연결한다는 점입니다. Android 실행 취소 동작 예시
‘실행 취소’를 눌렀을 때 메시지만 사라지고 프로젝트는 계속 보관돼 있다면 복구 기능이 아닙니다. 목록, 상태, 접근 경로가 함께 돌아와야 합니다. 처리 중에는 중복으로 복구를 요청하지 않도록 하고 결과를 확인한 뒤 복구되었다고 알려줍니다.
잠깐 보이는 안내만 복구 경로로 삼지 않습니다
사용자는 다른 화면을 보거나 긴 프로젝트 이름을 읽다가 실행 취소 기회를 놓칠 수 있습니다. 그래서 이 서비스에서는 안내가 사라진 뒤에도 보관함에서 복원할 수 있게 정합니다.
보관함 → ‘여름 캠페인’ 선택 → [보관 해제]
휴지통도 마찬가지입니다. 삭제가 유예되는 기간을 정했다면 사용자가 복구할 수 있는 위치와 종료 시점을 알 수 있어야 합니다. 기간은 운영 정책에 맞게 정하되 다른 서비스가 쓴 일수를 이유 없이 가져오지 않습니다.
실행 취소 안내의 노출 시간과 자료의 복구 가능 기간은 서로 다른 규칙입니다. 안내가 사라졌다고 곧바로 자료가 영구 삭제되는지, 별도 휴지통에서 계속 복원할 수 있는지 팀이 같은 답을 갖고 있어야 합니다.
복구가 실패한 상황도 화면에 남깁니다
복구를 요청했지만 서버에서 결과를 받지 못했다면 ‘복구되었습니다’라고 먼저 안내하지 않습니다. 원래 목록에 임시로 보여주더라도 실제 복원 여부를 확인하지 않은 상태와 완료 상태를 구분해야 합니다.
복구 결과를 확인하지 못했습니다. 보관함에서 현재 상태를 확인해 주세요.
복원할 때 무엇이 돌아오는지도 정합니다. 프로젝트 이름만 복구되고 작업이나 파일 연결은 돌아오지 않는다면 사용자는 원래 상태로 돌아왔다고 느끼기 어렵습니다. 함께 복원할 자료를 처음부터 한 묶음으로 정의해야 하는 이유입니다.
이름이 같은 새 프로젝트가 생겼거나 원래 위치가 없어졌을 때도 판단이 필요합니다. 사용자가 다시 이름을 붙여야 하는지, 다른 위치를 고르게 할지, 별도의 복구 위치에 보관할지 정합니다. 복구 버튼을 제공한다는 것은 이런 상황에서 자료를 어디로 돌려놓을지도 약속하는 일입니다.
삭제와 복구를 한 번의 흐름으로 점검합니다
삭제 기능을 검토할 때 확인 창만 캡처해두면 이후의 문제를 놓치기 쉽습니다. 대상 선택부터 결과 안내, 복구까지 연결해서 확인해보세요. 가상 서비스의 ‘여름 캠페인’을 기준으로 하면 다음 순서로 점검할 수 있습니다.
정리 목적을 확인합니다. 현재 목록에서 치우려는 것인지, 자료까지 없애려는 것인지 나눕니다. 보관으로 충분한 상황에 삭제를 먼저 제시하고 있지 않은지 봅니다.
대상과 범위를 읽습니다. 프로젝트 이름과 선택 개수가 맞는지, 내 화면과 팀 전체 중 어디에 영향을 주는지 확인합니다.
결과를 실제로 확인합니다. 목록에서 사라진 뒤 보관함이나 휴지통에서 찾습니다. 작업과 첨부자료도 안내한 방식으로 남아 있는지 확인합니다.
복구한 뒤 다시 사용합니다. 실행 취소와 보관함 복원 모두 시도합니다. 프로젝트를 열고 작업과 파일에 다시 접근할 수 있는지 확인합니다.
끝나지 않은 처리를 구분합니다. 일부 항목만 성공하거나 복구 결과가 불확실할 때 성공 메시지로 덮이지 않는지 봅니다.
기획서에는 화면보다 약속을 먼저 남깁니다
디자인과 개발에 전달할 내용을 길게 쓸 필요는 없습니다. 다음 질문에 같은 답을 할 수 있으면 시작할 수 있습니다.
보관과 삭제는 각각 무엇을 바꾸나요?
다른 팀원이 보고 있던 자료에도 영향을 주나요?
어떤 항목을 함께 복원하나요?
실행 취소 안내가 사라지면 어디에서 복구하나요?
되돌릴 수 없는 시점은 언제이며, 사용자에게 어떻게 알려주나요?
이 답이 빠져 있으면 디자이너는 복구 버튼을 그렸는데 개발 범위에는 복구할 데이터가 없는 상황이 생길 수 있습니다. 반대로 서버에는 복구할 자료가 남아 있어도 화면에 찾는 경로가 없으면 사용자는 이미 잃어버린 것으로 받아들일 수 있습니다.
좋은 삭제 경험은 사용자가 결과를 예상하고 가능한 실수는 바로잡을 수 있는 경험입니다. 모든 행동을 여러 번 확인시키는 방식보다, 정리 목적에 맞는 기능을 제공하고 약속한 복구 경로를 실제로 연결하는 일이 먼저입니다.
4PS는 서비스 화면을 설계할 때 버튼과 확인 창뿐 아니라 실행 이후의 상태와 복구 범위까지 함께 정리합니다. 삭제·보관·숨김이 섞여 운영 문의가 반복된다면 현재 화면과 처리 규칙을 알려주세요. 사용자가 기대하는 결과와 실제 동작이 어디에서 달라지는지부터 함께 살펴보겠습니다.
Latest Blogs
UX/UI
삭제 버튼을 누른 다음, 사용자는 돌아올 수 있나요?
삭제 버튼을 누른 다음, 사용자는 돌아올 수 있나요?
삭제 확인 창만으로는 사용자의 실수를 막기 어렵습니다. 보관과 휴지통, 영구 삭제를 구분하고 실행 취소부터 복구 이후의 상태까지 연결하는 UX 설계 기준을 살펴봅니다.
삭제 확인 창만으로는 사용자의 실수를 막기 어렵습니다. 보관과 휴지통, 영구 삭제를 구분하고 실행 취소부터 복구 이후의 상태까지 연결하는 UX 설계 기준을 살펴봅니다.
삭제 버튼보다 먼저, 무엇을 없앨지 정합니다
끝난 프로젝트를 목록에서 치우고 싶어 삭제 버튼을 눌렀습니다. 확인 창까지 읽고 실행했는데 잠시 뒤 팀원이 관련 파일을 찾습니다. 목록만 정리하려던 사람과 자료가 사라진 팀원이 서로 다른 결과를 예상한 것입니다.
삭제를 누르기 전에 한 번 더 물었다고 해서 이런 문제가 해결되지는 않습니다. 사용자가 없애려던 대상과 서비스가 실제로 없앤 대상이 달랐기 때문입니다. 버튼을 누르기 전에는 무엇이 바뀌는지, 누른 뒤에는 어디에서 되돌릴 수 있는지가 이어져야 합니다.
삭제 UX는 확인 창의 문구보다 데이터의 처리 방식을 먼저 정하는 작업입니다. 목록에서 숨기는 것인지, 사용을 중단하는 것인지, 저장된 자료까지 없애는 것인지 구분해야 화면도 분명해집니다.
이 글에서는 가상의 팀 프로젝트 서비스를 예로 들겠습니다. ‘여름 캠페인’ 프로젝트에는 일정, 작업 카드, 첨부파일이 있습니다. 팀은 종료된 프로젝트를 현재 작업 목록에서 정리하고 싶습니다. 이때 필요한 기능이 반드시 삭제인 것은 아닙니다.
사용자가 원하는 것은 정리일 수 있습니다
다음 두 요청은 비슷해 보이지만 처리 결과가 다릅니다.
“이번 주 목록에서는 안 보였으면 좋겠어요. 나중에 자료는 찾아야 해요.”
“잘못 만든 테스트 프로젝트예요. 첨부자료까지 모두 없애고 싶어요.”
첫 번째에는 보관이, 두 번째에는 삭제가 맞을 수 있습니다. 두 요청을 모두 휴지통 아이콘 하나로 해결하려고 하면 사용자가 결과를 추측해야 합니다. 기능 이름을 정하기 전에 실제로 남길 것과 없앨 것을 적어보세요.
행동 | 이 서비스에서 정한 결과 | 다시 찾는 곳 |
|---|---|---|
보관 | 현재 목록에서 제외하고 자료는 유지 | 보관함 |
휴지통으로 이동 | 일반 사용을 중단하고 복구 대상으로 유지 | 휴지통 |
영구 삭제 | 안내한 대상 자료를 복구할 수 없게 삭제 | 복구 불가 |
이 표는 가상 서비스의 정책 예시입니다. 보관이나 휴지통이라는 이름만 붙이면 자료가 자동으로 보존되는 것은 아닙니다. 실제 저장 방식과 복구 동작이 화면의 약속을 따라야 합니다.
확인 창에는 대상과 결과를 함께 보여줍니다
“정말 삭제하시겠습니까?”에는 빠진 정보가 많습니다
팀원이 ‘여름 캠페인’을 선택하고 삭제 메뉴를 열었다고 해보겠습니다. 확인 창에 다음 문장만 보이면 무엇을 판단할 수 있을까요?
정말 삭제하시겠습니까?
[취소] [확인]
이 문구에는 프로젝트 이름이 없습니다. 내 목록에서만 사라지는지, 팀 전체에서 사라지는지도 알 수 없습니다. 첨부파일이 함께 없어지는지도 설명하지 않습니다. 사용자가 확인을 눌렀다는 사실만으로 이런 결과까지 이해했다고 보기는 어렵습니다.
이 서비스가 프로젝트를 먼저 휴지통으로 옮기도록 설계했다면 화면에도 그 결과를 그대로 적습니다.
‘여름 캠페인’을 휴지통으로 이동할까요?
팀의 진행 중 목록에서 사라집니다. 작업과 첨부파일은 휴지통에서 함께 복구할 수 있습니다.
[프로젝트 유지] [휴지통으로 이동]
대상 이름, 영향을 받는 범위, 복구 방법을 읽고 선택할 수 있어야 합니다. ‘확인’을 ‘휴지통으로 이동’으로 바꾸는 것만으로 끝내지 않고 실제로 함께 이동하는 자료까지 맞춰야 합니다.
영구 삭제에는 다른 판단이 필요합니다
휴지통에 있는 프로젝트를 완전히 없앨 때는 같은 확인 창을 재사용하지 않습니다. 복구 가능한 이동과 복구할 수 없는 삭제는 결과가 다르기 때문입니다.
‘여름 캠페인’을 영구 삭제할까요?
이 프로젝트의 작업과 첨부파일이 삭제됩니다. 삭제한 자료는 이 서비스에서 복구할 수 없습니다.
[휴지통에 유지] [영구 삭제]
실제로 어떤 자료가 삭제되는지는 구현 범위를 확인해 작성해야 합니다. 공유 파일 원본은 남고 프로젝트 안 연결만 끊어진다면 ‘첨부파일이 삭제됩니다’라고 안내해서는 안 됩니다. 삭제 작업이 일정 시간 뒤에 처리된다면 즉시 사라진다고 표현하는 것도 맞지 않습니다.
GOV.UK 디자인 시스템은 쉽게 되돌릴 수 없는 심각한 파괴적 행동에 경고 버튼을 제한적으로 사용하고, 추가 확인 단계를 두도록 안내합니다. 모든 정리 작업을 같은 빨간 버튼으로 만들기보다 결과의 무게를 구분할 근거가 됩니다. GOV.UK 경고 버튼 지침
여러 개를 선택했다면 개수를 숨기지 않습니다
목록에서 프로젝트 세 개를 선택한 상황이라면 확인 창에도 ‘선택한 프로젝트 3개’라고 표시합니다. 선택 목록이 화면 밖에 있어도 현재 작업의 범위를 다시 확인할 수 있어야 합니다. 중요한 항목은 이름을 함께 보여주는 방법도 검토할 수 있습니다.
이 중 하나만 이동하지 못했을 때의 결과도 정해야 합니다. 두 개는 이동했고 하나가 남았다면 ‘완료’ 한마디로 끝내지 않습니다.
프로젝트 2개를 휴지통으로 이동했습니다. ‘겨울 캠페인’은 이동하지 못했습니다. 목록을 확인해 주세요.
이런 결과 안내는 부가 문구가 아닙니다. 사용자가 같은 작업을 다시 할지 결정하는 데 필요한 정보입니다.
실행 취소는 버튼이 아니라 복구 동작입니다
작은 실수를 바로 고칠 수 있게 합니다
프로젝트를 보관한 직후 잘못 선택했다는 사실을 알아차렸다면 화면 아래의 짧은 안내에서 바로 되돌릴 수 있게 할 수 있습니다.
‘여름 캠페인’을 보관했습니다. [실행 취소]
사용자는 보관함을 찾아 들어가지 않고도 방금 한 행동을 되돌립니다. Android 공식 문서도 보관 안내에 실행 취소 동작을 연결해 항목을 다시 꺼내는 예시를 설명합니다. 중요한 것은 안내를 지우는 버튼이 아니라 원래 상태로 돌리는 동작을 연결한다는 점입니다. Android 실행 취소 동작 예시
‘실행 취소’를 눌렀을 때 메시지만 사라지고 프로젝트는 계속 보관돼 있다면 복구 기능이 아닙니다. 목록, 상태, 접근 경로가 함께 돌아와야 합니다. 처리 중에는 중복으로 복구를 요청하지 않도록 하고 결과를 확인한 뒤 복구되었다고 알려줍니다.
잠깐 보이는 안내만 복구 경로로 삼지 않습니다
사용자는 다른 화면을 보거나 긴 프로젝트 이름을 읽다가 실행 취소 기회를 놓칠 수 있습니다. 그래서 이 서비스에서는 안내가 사라진 뒤에도 보관함에서 복원할 수 있게 정합니다.
보관함 → ‘여름 캠페인’ 선택 → [보관 해제]
휴지통도 마찬가지입니다. 삭제가 유예되는 기간을 정했다면 사용자가 복구할 수 있는 위치와 종료 시점을 알 수 있어야 합니다. 기간은 운영 정책에 맞게 정하되 다른 서비스가 쓴 일수를 이유 없이 가져오지 않습니다.
실행 취소 안내의 노출 시간과 자료의 복구 가능 기간은 서로 다른 규칙입니다. 안내가 사라졌다고 곧바로 자료가 영구 삭제되는지, 별도 휴지통에서 계속 복원할 수 있는지 팀이 같은 답을 갖고 있어야 합니다.
복구가 실패한 상황도 화면에 남깁니다
복구를 요청했지만 서버에서 결과를 받지 못했다면 ‘복구되었습니다’라고 먼저 안내하지 않습니다. 원래 목록에 임시로 보여주더라도 실제 복원 여부를 확인하지 않은 상태와 완료 상태를 구분해야 합니다.
복구 결과를 확인하지 못했습니다. 보관함에서 현재 상태를 확인해 주세요.
복원할 때 무엇이 돌아오는지도 정합니다. 프로젝트 이름만 복구되고 작업이나 파일 연결은 돌아오지 않는다면 사용자는 원래 상태로 돌아왔다고 느끼기 어렵습니다. 함께 복원할 자료를 처음부터 한 묶음으로 정의해야 하는 이유입니다.
이름이 같은 새 프로젝트가 생겼거나 원래 위치가 없어졌을 때도 판단이 필요합니다. 사용자가 다시 이름을 붙여야 하는지, 다른 위치를 고르게 할지, 별도의 복구 위치에 보관할지 정합니다. 복구 버튼을 제공한다는 것은 이런 상황에서 자료를 어디로 돌려놓을지도 약속하는 일입니다.
삭제와 복구를 한 번의 흐름으로 점검합니다
삭제 기능을 검토할 때 확인 창만 캡처해두면 이후의 문제를 놓치기 쉽습니다. 대상 선택부터 결과 안내, 복구까지 연결해서 확인해보세요. 가상 서비스의 ‘여름 캠페인’을 기준으로 하면 다음 순서로 점검할 수 있습니다.
정리 목적을 확인합니다. 현재 목록에서 치우려는 것인지, 자료까지 없애려는 것인지 나눕니다. 보관으로 충분한 상황에 삭제를 먼저 제시하고 있지 않은지 봅니다.
대상과 범위를 읽습니다. 프로젝트 이름과 선택 개수가 맞는지, 내 화면과 팀 전체 중 어디에 영향을 주는지 확인합니다.
결과를 실제로 확인합니다. 목록에서 사라진 뒤 보관함이나 휴지통에서 찾습니다. 작업과 첨부자료도 안내한 방식으로 남아 있는지 확인합니다.
복구한 뒤 다시 사용합니다. 실행 취소와 보관함 복원 모두 시도합니다. 프로젝트를 열고 작업과 파일에 다시 접근할 수 있는지 확인합니다.
끝나지 않은 처리를 구분합니다. 일부 항목만 성공하거나 복구 결과가 불확실할 때 성공 메시지로 덮이지 않는지 봅니다.
기획서에는 화면보다 약속을 먼저 남깁니다
디자인과 개발에 전달할 내용을 길게 쓸 필요는 없습니다. 다음 질문에 같은 답을 할 수 있으면 시작할 수 있습니다.
보관과 삭제는 각각 무엇을 바꾸나요?
다른 팀원이 보고 있던 자료에도 영향을 주나요?
어떤 항목을 함께 복원하나요?
실행 취소 안내가 사라지면 어디에서 복구하나요?
되돌릴 수 없는 시점은 언제이며, 사용자에게 어떻게 알려주나요?
이 답이 빠져 있으면 디자이너는 복구 버튼을 그렸는데 개발 범위에는 복구할 데이터가 없는 상황이 생길 수 있습니다. 반대로 서버에는 복구할 자료가 남아 있어도 화면에 찾는 경로가 없으면 사용자는 이미 잃어버린 것으로 받아들일 수 있습니다.
좋은 삭제 경험은 사용자가 결과를 예상하고 가능한 실수는 바로잡을 수 있는 경험입니다. 모든 행동을 여러 번 확인시키는 방식보다, 정리 목적에 맞는 기능을 제공하고 약속한 복구 경로를 실제로 연결하는 일이 먼저입니다.
4PS는 서비스 화면을 설계할 때 버튼과 확인 창뿐 아니라 실행 이후의 상태와 복구 범위까지 함께 정리합니다. 삭제·보관·숨김이 섞여 운영 문의가 반복된다면 현재 화면과 처리 규칙을 알려주세요. 사용자가 기대하는 결과와 실제 동작이 어디에서 달라지는지부터 함께 살펴보겠습니다.