마스크 시대의 취소 버튼(1)
'취소'의 신묘한 힘
묘한 Action word, '취소'
누가 UX Writing을 할 때 가장 많이 쓰는 단어가 뭐냐고 물으면 저는 망설임 없이 '확인'과 '취소'를 뽑습니다. 몇 년 전 모 휴대폰 제조사에 일했을 때 휴대폰 OS와 기본 탑재 앱의 텍스트를 모아 워드 클라우드를 만든 적이 있었는데, 거기에서도 정중앙에 떡하니 '취소'가 있었죠. 생각보다 '확인'이 적었던 이유에 대해선 다음 '확인' 편에서 다시 설명하기로 합니다.(언젠가...?)
취소, 영어로 Cancel은 정말이지 이상한 레이블이 아닐 수 없습니다.
취소의 사전적 의미는 '발표한 의사를 거두어들이거나 예정된 일을 없애버림'입니다.
그러나 실제 UI에서는 1) 하려던 걸 안 하겠다고 번복하는 행위 2) 아직 끝나지 않았는데도 하던 걸 때려치우는 행위 3) 심지어는 했던 것을 되돌리려는 일 모두를 의미하죠.
한 단어가 함의하고 있는 행위가 이와 같이 묘하게 비슷하면서도 다르기 때문에 종종 재미있지만 골치 아픈 일이 생기곤 합니다. 우리 마음속의 취소라는 단어가 가진 그 미묘한 심상이 UI에서 이상한 케이스들 만들어 내기 때문에, 한 번쯤은 함께 짚어보면 좋을 것 같아 2년 만에 개시하는 brunch 글의 첫 주제로 삼아 봅니다.
앞으로 2편에 걸쳐서 이 취소라는 묘한 Action word에 대해 알아볼 예정입니다.
먼저 간단하게 UI에서의 취소의 의미와 쓰임, 적용 시 주의점에 대해서 이야기하고, 다음 편에서는 얼마 전 발견한 재미있는 case - Face ID 에러 팝업의 취소 버튼과 그 버튼 때문에 생긴 문제, 그 문제가 해결된 과정 - 을 살펴보면서 취소라는 단순해 보이는 액션이 기획 및 개발과 얼마나 많은 연관 관계를 갖고 있는지에 대해서 이야기해보려고 합니다.
모바일 팝업 왼쪽 버튼 취소의 역할
앱을 사용하면서 자주 보는 2 버튼 팝업의 왼쪽에는 거의 90% 확률로 취소 버튼이 자리하고 있습니다.
2 버튼 팝업의 태생적인 성질 때문이죠.
많은 분들이 잘 알고 계시겠지만 그래도 한 번쯤 짚고 넘어가자면,
모바일 버전의 팝업 오른쪽 버튼은 Positive, 순방향, 긍정과 수긍, 예정된 Flow로 전진이라는 역할을 수행합니다. 왜 오른쪽에 Positive를 놓냐에 대해서는 여러 썰이 있지만, 개인적으로는 오른손잡이 사용자의 엄지 손가락 가동 범위를 고려하여 모바일에서는 팝업의 오른쪽 버튼에 Positive action word를 배정한다는 이야기가 일리가 있다고 생각합니다.
'어랏, 우리 서비스는 PC 버전 앱, 게다가 Windows와 Mac도 다 지원하는데 일괄 오른쪽에 취소 버튼을 놓고 있는데....?'라고 생각하신 분이 있다면, 팝업 텍스트 작성하실 때 조금 더 세심한 케어가 필요하다고 조언드리고 싶네요.
이 이야기도 다음에 다시 이야기해 봅시다. (왜 자꾸 약속하는가... 어쩌려고 약속하는가... 나는...)
오른쪽에 Positive 가 있다면 그 반대편에는 무엇이 있어야 하는지는 비교적 분명합니다.
빛과 그림자, 양과 음, 백과 흑이 쌍을 이루듯 모바일 버전의 팝업 왼쪽 버튼에는 Negative, 역방향, 부정과 거부, 예정된 Flow로부터의 후퇴 또는 중지 역할을 하는 단어가 나와야 합니다.
문제는 오른쪽 액션 워드로 사용할 수 있는 단어, 주로 용언(동사)인 어휘는 상대적으로 많지만(개인적으로 레거시나 가이드 무시해도 되고 공간만 충분히 주어진다면 무한히 만들 수 있을 것 같습니다만) 그들의 짝꿍이 될 수 있는 부정적인 동사는 몇 개 안된다는 것입니다.
그 몇 개 안 되는 부정어의 대장은 역시 취소죠.
이 '취소'라는 용언은 일단 내가 싸지른 저지른 일을 중단하고 의사를 철회한다는 의미를 갖고 있기 때문에, 팝업을 발현시킨 이전 상황까지 커버할 수 있는 상당한 힘을 가진 동사입니다.
실은 2 버튼 팝업의 왼쪽 '취소' 버튼을 볼 때마다 저는 거부할 수 없는 두 가지 다른 마음의 소리를 듣습니다.
경고를 동반한 확인(Confirm) 팝업. 잔소리가 좀 심한 편아이코, 이거 내가 잘못 생각했네.
큰일 날뻔했다, 일단 안 할래.
or
아우, 뭐라고 조잘대는 거야. 시끄러! 꺼져.
'취소'의 역할: 선택권 제공 VS 책임 회피
기술적인 측면에서 컨펌 팝업(사용자 의사 재확인용 팝업)에서 취소 버튼은 왜 존재해야 할까요?
더 직접적으로 묻자면 컨펌 팝업에 왜 1 버튼 팝업이 아닌 2 버튼 팝업을 쓰는 걸까요? 아니, 더 까놓고 물어보면 UX 디자이너들은 왜 컨펌 팝업에 2 버튼을 선호할까요?
실제로 UX writing을 하다 보면 1 버튼 팝업을 써야 하거나, 아예 팝업을 안 써도 될 상황에서도 UX 디자이너들이 2 버튼 컨펌 팝업을 굳이 넣고 싶어 하는 경우가 종종 있습니다.
그분들의 생각을 제가 다 알 수 없지만 제 나름대로 추측해 보자면, 다음과 같은 배려와 걱정이 항시 UX 디자이너의 마음에 안쪽에 도사리고 있는 것 같습니다.
1) 사용자의 의사를 존중하기 때문에 선택권을 주려고 함
Flow의 갈림길에서 못 먹어도 고할지, 여기서 스톱할지 결정하는 행위는 UI에서 무척 중요합니다.
태스크를 진행해서 우리가 얻고자 하는 결과까지 사용자를 끌어 올 수 있을 것이냐가 서비스 성패를 좌우하기 때문이죠. 정말 중요한 결정의 순간에는 사용자의 동의를 받고 함께 나아가야 합니다.
사용자가 중요한 결정의 순간에, 또는 상당히 위험할 수 있는 상황에서(예를 들어 데이터가 삭제된다거나, 낙장 불입 이제부터는 전진만 가능한 상황이 펼쳐진다거나 하는) 사용자 본인의 결정이 존중받는다고 느낄 때 서비스에 대한 신뢰도와 애착은 높아질 수밖에 없습니다.
아서왕의 기사 거웨인의 결혼 이야기에서처럼 '사용자가 진정으로 원하는 것은 무엇인가? 그것은 그들의 의지대로 행하는 것이다'와 같은 생각이 UX 디자이너 마음속에 자리하고 있을 수밖에 없는 건 어쩌면 당연한 것일지도 모르겠습니다.
2) 나중에 내 책임이 아니라고 말하고 싶음
선택은 책임을 동반합니다. 바꿔 말하면 내가 선택하지 않으면 내가 책임질 일이 없죠. UX writing을 하다가 불필요해 보이는 팝업을 빼자고 요청하면 이런 생각을 나이브하게(!) 밝히는 UX 디자이너들이 있었습니다.
사용자가 실수로 잘못 누를 수 있으니까요. 그럼 나중에 문제 생길 수 있잖아요.
잘 모르고 그랬다가 나중에 이거 삭제된 거 복구 안되면 VOC 생긴다고요.
이거 컨펌 팝업 없이 하다가 legal issue 생기면 어떻게 해요?
전 잘 모르겠는데... 일단 안전하게 컨펌 팝업 주는 게 좋을 것 같아요.
중요한 이슈, 예를 들어 permanently delete 나 심각한 프라이버시 노출 등이 우려되는 문제라면 저도 군말 없이 씨게 세게 팝업을 작성하곤 했습니다.
사용자와 서비스 모두를 보호하기 위해선 그럴 수 있고 그래야 하죠.
문제는 꼭 넣지 않아도 될 팝업을 넣으므로 마치 사용자의 전진을 바라지 않는 것처럼 취소 버튼을 준비하는 경우입니다.
이런 도망갈 구석을 만드는 컨펌 팝업, 그 팝업의 취소 버튼은 서비스를 걱정쟁이로 보이게 만듭니다.
서비스를 만드는 사람들은 언제 사용자에게 선택권을 줄지, 주지 않을지 세심하게 결정해야 합니다.
모든 사람에게 취소 버튼을 주고 '잘못돼도 내 책임은 아니야 난 그만둘 기회를 분명히 줬다고!'라며 고개를 돌려버린다면 성실한 UX 디자이너라고 보기 어렵겠죠.
그럼 언제, 뭘 물어봐야 할까?
유치원 다닐 무렵에 집에 있다가 엄마에게 '엄마 나 쉬 싸도 돼요?'라고 물었던 적이 있었습니다.
그때 엄마는 아주 어처구니없어하시면서 '그런 건 물어보지 마. 옷에 싸지 말고 바로 화장실 가라고!'라고 하셨죠. 당시엔 '아, 쉬 싸러 가는 건 안 물어봐도 되는구나...' 이런 생각이 들면서 뭔가 새로운 사실을 알게 된 것 같은 느낌이었어요.
초중고를 다닐 때는 화장실 다녀와도 되냐고 묻지 않으면 안 됐었습니다. 묻지 않고 화장실에 간다는 것은 교권에 도전하는(?) 아무튼 상상할 수 없는 일이었습니다. 신체의 자유가 없던 시절이었으니까요.
그러다 대학에 가니 강의 중 화장실에 슬그머니 다녀올 수 있더군요. 대학 1학년 때에는 그게 좀 어색하게 느껴지더라고요. 아 물론 지금 직장에서는 물론 제가 가고 싶을 때 갑니다. 누구에게도 묻지 않아요.
지금 생각하면 중고등학교 당시 배뇨감 해소에 대해 타인에게 허락을 받아야 했던 그 상황이 매우 웃기고 이상하게 느껴집니다만, 아무튼 개인적으로 의사를 묻는 행위가 모든 맥락에서 절대적으로 환영받는 것은 아니라는 것을, 묻지 않아도 될 것들과 물어야 되는 것들은 상황에 따라 다를 수 있다는 것을 이런 소소한 계기를 통해 학습하게 되었습니다.
컨펌 팝업의 사용 역시 마찬가지입니다. 물어봐야 하는 일, 물어봐야 하는 상황은 사용 맥락에 따라 다릅니다.
굳이 취소시키지 않아도 될 일, 중지시키지 않아도 될 일이라면, 가능하면 묻지 않고 우리의 사용자를 빠르게 앞으로 나아갈 수 있도록 도와줘야 합니다.
퇴로를 열어줄 때는 언제이고 사용자에게 선택권을 주어야 할 때가 언제인지에 대해 디자이너 저마다의 기준으로 갖고 있어야 합니다.
팝업 배치를 결정하기 위해 사용자 인식 가능성, 오류 발생 빈도, 법률적 이슈 발생의 위험성을 종합적으로 고려해야 하겠죠. 데이터(오류 발생 빈도, VOC 리스트, 태스크 수행 속도 등이 도움이 될 수 있겠습니다.)에 기반하여 결정한다면 정말 좋겠고, 쓸만한 데이터가 없다면 본인의 디자인 논리와 철학에 기반하여 나름의 원칙을 만들면 됩니다.
사용자의 자연스러운 서비스 여정을 위해 뺄 때는 빼고 줄 때는 주는 고민과 배려가 항상 필요합니다.
오늘의 요약
UI 텍스트 '취소'는 1) 하려던 걸 안 하겠다고 번복하는 행위 2) 아직 끝나지 않았는데도 하던 걸 때려치우는 행위 3) 심지어는 했던 것을 되돌리려는 의미를 갖고 있습니다.
모바일 버전의 팝업에서 오른쪽 버튼은 Positive, 순방향, 긍정과 수긍, 예정된 Flow로 전진을 의미하고 왼쪽 버튼은 negative, 역방향, 부정과 거부, 예정된 Flow로부터의 후퇴 또는 중지의 역할을 합니다. '취소'는 그중 negative 버튼의 대장입니다.
취소 버튼을 제공한다는 것은 선택권 부여와 책임 회피 그 어딘가에 있습니다. 대상, 맥락에 따라 제공할 때와 스킵할 때를 구분하는 디자이너의 고민과 배려가 필요합니다.
다음 2편에서는 제가 지난주에 경험한 메신저 앱 LINE, 카카오톡에서 로그인 시 등장하는 Face ID 인식 오류 팝업, 그 팝업의 취소 버튼 사용 케이스에 대해서 이야기해 볼까 합니다.
ios 13.6(17G68)로 업데이트되면서 시원하게 해결된 재미있는 문제죠.
마스크 시대의 취소 버튼이라는 이번 글의 제목은 이 케이스 때문에 쓰게 되었습니다.
2년 가까이 brunch를 쉬다가 주 2회 게시글 올리기 챌린지를 시작하니 아주 빡세네요.
아이고야.
