묘한 Action word, ‘취소’
누가 UX Writing을 할 때 가장 많이 쓰는 단어가 뭐냐고 물으면 저는 망설임 없이 ‘확인’과 ‘취소’를 뽑습니다. 몇 년 전 모 휴대폰 제조사에 일했을 때 휴대폰 OS와 기본 탑재 앱의 텍스트를 모아 워드 클라우드를 만든 적이 있었는데, 거기에서도 정중앙에 떡하니 ‘취소’가 있었죠. 생각보다 ‘확인’이 적었던 이유에 대해선 언젠가 쓸 ‘확인’ 편에서 다시 설명하기로 합니다.
취소, 영어로 Cancel은 정말이지 이상한 레이블이 아닐 수 없습니다. 취소의 사전적 의미는 ‘발표한 의사를 거두어들이거나 예정된 일을 없애버림’입니다. 그러나 실제 UI에서는 이런 일을 의미하죠.
- 하려던 걸 안 하겠다고 번복하는 행위
- 아직 끝나지 않았는데도 하던 걸 때려치우는 행위
- 심지어는 했던 것을 되돌리려는 일 모두
한 단어가 함의하고 있는 행위가 묘하게 비슷하면서도 다르기 때문에, 종종 재미있지만 골치 아픈 일이 생기곤 합니다. 우리 마음속의 취소라는 단어가 가진 그 미묘한 심상이 UI에서 이상한 케이스를 만들어 내기 때문이죠. 사례들을 한 번쯤은 함께 짚어보면 좋을 것 같아 첫 글의 주제로 삼아 봅니다.
지금부터 ‘취소’라는 이 묘한 Action word에 대해 알아볼 예정입니다. 먼저 간단하게 UI에서의 취소의 의미와 쓰임, 적용 시 주의점에 대해서 이야기하고, 다음 편에서는 얼마 전 발견한 재미있는 케이스를 알아볼 겁니다. 구체적으로 페이스 ID 에러 팝업의 취소 버튼과 버튼 때문에 생긴 문제, 그 문제가 해결된 과정을 살펴보면서 취소라는 단순해 보이는 액션이 기획 및 개발과 얼마나 많은 연관 관계를 갖고 있는지에 대해서 이야기해보려고 합니다.
모바일 팝업 왼쪽 버튼 취소의 역할
앱을 사용하면서 자주 보는 2 버튼 팝업의 왼쪽에는 거의 90% 확률로 취소 버튼이 자리하고 있습니다. 2 버튼 팝업의 태생적인 성질 때문이죠.
많은 분들이 잘 알고 계시겠지만 그래도 한 번쯤 짚고 넘어가자면, 모바일 버전의 팝업 오른쪽 버튼은 ‘Positive’, 순방향을 의미합니다. 긍정과 수긍, 예정된 Flow로 전진한다는 역할을 수행하죠. 왜 오른쪽에 Positive를 두는지에 대해서는 여러 썰이 있지만, 개인적으로는 오른손잡이 사용자의 엄지 손가락 가동 범위를 고려하여 오른쪽에 배정한다는 이야기가 일리 있다고 생각합니다.
어랏? 우리 서비스는 PC 버전 앱도 지원하고, 심지어는 Windows와 Mac도 다 지원하는데 일괄 오른쪽에 취소 버튼을 놓고 있는데…?
이렇게 생각하신 분이 있다면, 팝업 텍스트 작성하실 때 조금 더 세심한 케어가 필요하다고 조언 드리고 싶네요.
어쨌든, 오른쪽에 Positive가 있다면 반대편에는 무엇이 있어야 하는지는 비교적 분명합니다. 빛과 그림자, 양과 음, 백과 흑이 쌍을 이루듯 모바일 버전의 팝업 왼쪽 버튼에는 Negative가 있습니다. 역방향, 부정과 거부, 예정된 Flow로부터의 후퇴 또는 중지 역할을 하는 단어가 나와야 하죠.
문제는 오른쪽 액션 워드로 사용할 수 있는 단어, 주로 용언(동사)인 어휘는 상대적으로 많지만 그들의 짝꿍이 될 수 있는 부정적인 동사는 몇 개 안된다는 것입니다. 그 몇 개 안 되는 부정어의 대장은 역시 ‘취소’죠. 이 ‘취소’라는 용언은 일단 내가 싸지른 저지른 일을 중단하고 의사를 철회한다는 의미를 갖고 있습니다. 그래서 팝업을 발현시킨 이전 상황까지 커버할 수 있는 상당한 힘을 가진 동사입니다.
실은 2 버튼 팝업의 왼쪽 ‘취소’ 버튼을 볼 때마다 저는 거부할 수 없는 두 가지 다른 마음의 소리를 듣습니다.
아이코, 이거 내가 잘못 생각했네. 큰일 날뻔했다, 일단 안 할래.
이게 아니라면?
시끄러, 꺼져.
‘취소’의 역할: 선택권 제공이냐, 책임 회피냐
기술적인 측면에서 컨펌 팝업(사용자 의사 재확인용 팝업)에서 취소 버튼은 왜 존재해야 할까요? 더 직접적으로 묻자면 컨펌 팝업에 왜 1 버튼 팝업이 아닌 2 버튼 팝업을 쓰는 걸까요? 아니, 더 까놓고 물어보면 UX 디자이너들은 왜 컨펌 팝업에 2 버튼을 선호할까요?
실제로 UX writing을 하다 보면 1 버튼 팝업을 써야 하거나, 아예 팝업을 안 써도 될 상황에서도 UX 디자이너들이 2 버튼 컨펌 팝업을 굳이 넣고 싶어 하는 경우가 종종 있습니다. 그분들의 생각을 제가 다 알 수 없지만 제 나름대로 추측해 보자면, 다음과 같은 배려와 걱정이 항시 UX 디자이너의 마음에 안쪽에 도사리고 있는 것 같습니다.
1) 사용자의 의사를 존중하기 때문에 선택권을 주려고 함
Flow의 갈림길에서 ‘못 먹어도 고’할지, 여기서 스톱할지 결정하는 행위는 UI에서 무척 중요합니다. 태스크를 진행해서 우리가 얻고자 하는 결과까지 사용자를 끌어 올 수 있을 것이냐가 서비스 성패를 좌우하기 때문이죠. 정말 중요한 결정의 순간에는 사용자의 동의를 받고 함께 나아가야 합니다.
사용자가 중요한 결정의 상황에서, 또는 상당히 위험할 수 있는 상황에서(예를 들어 데이터가 삭제된다거나 낙장 불입이니 이제부터는 전진만 가능한 상황이 펼쳐진다거나 하는) 본인의 결정이 존중받는다고 느낄 때 서비스에 대한 신뢰도와 애착은 높아질 수밖에 없습니다.
아서왕의 기사 거웨인의 결혼 이야기에서처럼 ‘사용자가 진정으로 원하는 것은 무엇인가? 그것은 그들의 의지대로 행하는 것이다’와 같은 생각이 UX 디자이너 마음속에 자리하고 있을 수밖에 없는 게 당연한 것일지도 모르겠습니다.
2) 나중에 내 책임이 아니라고 말하고 싶음
선택은 책임을 동반합니다. 바꿔 말하면 내가 선택하지 않으면 내가 책임질 일이 없죠. UX writing을 하다가 불필요해 보이는 팝업을 빼자고 요청하면 이런 생각을 나이브하게(!) 밝히는 UX 디자이너들이 있었습니다.
사용자가 실수로 잘못 누를 수 있으니까요. 그럼 나중에 문제 생길 수 있잖아요.
잘 모르고 그랬다가 나중에 이거 삭제된 거 복구 안 되면 VOC 생긴다고요.
이거 컨펌 팝업 없이 하다가 regal issue 생기면 어떻게 해요?
전 잘 모르겠는데… 일단 안전하게 컨펌 팝업 주는 게 좋을 것 같아요.
중요한 이슈, 예를 들어 permantly delete나 심각한 프라이버시 노출 등이 우려되는 문제라면 저도 군말 없이 세게 팝업을 작성하곤 했습니다. 사용자와 서비스 모두를 보호하기 위해선 그럴 수 있고, 그래야 하죠.
문제는 꼭 넣지 않아도 될 팝업을, 마치 사용자의 전진을 바라지 않는 것처럼 준비하는 경우입니다. 이렇게 도망갈 구석을 만드는 컨펌 팝업, 그 팝업의 취소 버튼은 서비스를 걱정쟁이로 보이게 만듭니다.
서비스를 만드는 사람들은 언제 사용자에게 선택권을 줄지, 주지 않을지 세심하게 결정해야 합니다. 모든 사람에게 취소 버튼을 주고 ‘잘못돼도 내 책임은 아니야, 난 그만둘 기회를 분명히 줬다고!’라며 고개를 돌려버린다면 성실한 UX 디자이너라고 보기 어렵겠죠.
그럼 언제, 뭘 물어봐야 할까?
유치원 다닐 무렵에 집에 있다가 엄마에게 “엄마 나 쉬 싸도 돼요?”라고 물었던 적이 있었습니다. 그러자 엄마는 아주 어처구니없어하시면서 “그런 건 물어보지 마. 옷에 싸지 말고 바로 화장실 가라고!”라고 하셨죠. 당시엔 “아, 쉬 싸러 가는 건 안 물어봐도 되는구나…” 라는 생각이 들면서 뭔가 새로운 사실을 알게 된 것 같은 느낌이었어요.
반면 초중고를 다닐 때는 화장실 다녀와도 되냐고 묻지 않으면 안 됐습니다. 묻지 않고 화장실에 간다는 것은 교권에 도전하는(?) 아무튼 상상할 수 없는 일이었습니다. 신체의 자유가 없던 시절이었으니까요. 그러다 대학에 가니 강의 중 화장실에 슬그머니 다녀올 수 있더군요. 1학년 때에는 그게 좀 어색하게 느껴졌어요. 직장에서는 물론 제가 가고 싶을 때 갑니다. 누구에게도 묻지 않아요.
지금 생각하면 중고등학교 당시 배뇨감 해소에 대해 타인에게 허락을 받아야 했던 그 상황이 매우 웃기고 이상하게 느껴집니다만, 아무튼 개인적으로 의사를 묻는 행위가 모든 맥락에서 절대적으로 환영받는 것은 아닙니다. 묻지 않아도 될 것들과 물어야 되는 것들은 상황에 따라 다를 수 있다는 것을 이런 소소한 계기를 통해 학습하게 되었죠.
컨펌 팝업의 사용 역시 마찬가지입니다. 물어봐야 하는 일, 물어봐야 하는 상황은 사용 맥락에 따라 다릅니다. 굳이 취소시키지 않아도 될 일, 중지시키지 않아도 될 일이라면 우리의 사용자가 빠르게 앞으로 나아갈 수 있도록 도와줘야 합니다. 퇴로를 열어줄 때는 언제고 사용자에게 선택권을 주어야 할 때가 언제인지에 대해 디자이너 저마다의 기준을 갖고 있어야 합니다.
팝업 배치를 결정하기 위해 사용자 인식 가능성, 오류 발생 빈도, 법률적 이슈 발생의 위험성을 종합적으로 고려해야 하겠죠. 데이터(오류 발생 빈도, VOC 리스트, 태스크 수행 속도 등이 도움이 될 수 있겠습니다.)에 기반하여 결정한다면 정말 좋겠고, 쓸 만한 데이터가 없다면 본인의 디자인 논리와 철학에 기반하여 나름의 원칙을 만들면 됩니다.
사용자의 자연스러운 서비스 여정을 위해 빼고 줄 때는 주는 고민과 배려가 항상 필요한 것입니다.
현재까지 요약
- UI 텍스트 ‘취소’는 1) 하려던 걸 안 하겠다고 번복하는 행위 2) 끝나지 않았는데도 하던 걸 때려치우는 행위 3) 심지어는 했던 것을 되돌리려는 의미를 갖고 있습니다.
- 모바일 버전의 팝업에서 오른쪽 버튼은 Positive를 의미합니다. 순방향, 긍정과 수긍, 예정된 Flow로 전진을 의미하죠. 반면 왼쪽 버튼은 negative를 의미합니다. 역방향, 부정과 거부, 예정된 Flow로부터의 후퇴 또는 중지의 역할을 합니다. ‘취소’는 그중 negative 버튼의 대장입니다.
- 취소 버튼을 제공한다는 것은 선택권 부여와 책임 회피 그 어딘가에 있습니다. 대상, 맥락에 따라 제공할 때와 스킵할 때는 구분하는 디자이너의 고민과 배려가 필요합니다.
하루 백번 겪는 실패: 마스크 시대 Face ID의 로그인 실패
아이폰 사용자는 하루에 몇 번이나 휴대폰을 깨우고 로그인할까요. 본인이 얼마나 헤비 유저인지, 얼마나 많은 앱에 로그인 설정을 걸어 놓았는지에 따라 천차만별이겠지만 저는 평균 100번 정도의 휴대폰 깨우기를 한다고 스크린 타임이 알려주었네요.
저는 Face ID를 설정해두고 잠금을 해제합니다. 아시다시피 Face ID는 너무나도 편하기 때문에 한 번 사용하기 시작한 이후에는 그전의 상태로 돌아갈 수 없는 기능이죠. 그러니까 소금구이 먹다가 양념구이로 넘어가면 다시 소금구이로 돌아갈 수 없는, 그런 강렬한 충성도를 갖게 하는 기능인 것입니다.
그런데 이 Face ID 때문에 하루의 대부분을 마스크를 쓰고 생활했던 작년 한 해 동안 저는 하루에도 수십 번, 아니 백 번 넘게 실패를 겪을 수밖에 없었습니다.
네, 그래요. Face ID 인식 실패. 마스크를 쓰고 화면을 밀어 올리면, 간질간질한 진동을 느끼고 흔들리는 애니메이션을 보면서 애플 특유의 한국어 로컬리제이션, 영 어색한 그 음슴체를 읽어야 하곤 했습니다.
위로 쓸어올려서 Face ID 사용 또는 암호 입력
얼굴이 인식되지 않음
이 화면의 ‘취소’ 버튼은 취소할 행위를 ‘위로 쓸어 올려 잠금을 해제하려 하는 의도’로 규정합니다. 즉, 잠금을 해제하려는 사용자의 의사를 철회한다고 보는 것이죠. 실제로 취소 버튼을 누르면 직전 화면인 잠금화면으로 다시 되돌아 갑니다.
여기까지는 문제가 없습니다. 실제로 직전에 사용가 수행한 행위가 있기 때문이죠. 그러나 개별 앱의 잠금을 해제할 때에는 다른 상황이 펼쳐집니다.
카카오톡 Face ID 로그인 실패: 무엇을 누르든 암호 입력을 보게 될 것이다
LINE에 다니지만 카카오톡도 자주 쓰는지라 매번 Face ID로 잠금을 해제하면서 사용했습니다. 그러다 코로나19 대폭발 이후 마스크를 생활화하면서 하루에도 수십 번 이 팝업을 보게 되었습니다.
카카오톡 비밀번호 설정 상태에서 카카오톡 실행→Face ID 인식→실패 시에 나오는 팝업입니다. 팝업 바디를 타이틀과 디스크립션으로 나눴습니다. ios 네이티브 팝업에서 어느 정도 요소를 가져온 것 겉아요. 기존에 쓰던 OS 네이티브 팝업을 그대로 뿌렸을 수도 있겠습니다만. (카카오톡 말고 이런 스타일 쓰는 앱들이 몇 개 있더군요)
그렇다고 해서 뭐라고 안 할 수 없는 게… 아니, 이 팝업 레이블은 정말이지 너무 대충 썼습니다. 현재 상황인 ‘얼굴이 인식되지 않음’을 밝힌 것까진 좋아요. 그러나 2 버튼 팝업을 쓰려면 디스크립션에 뭔가 뭘 어떻게 할 건지 묻든지, 디렉션을 주든지, 앞으로 어떻게 될 거라든지 정보를 더 제공하든지 해야 합니다. 그도 저도 아니면 아예 아무 말도 말든지. 덜렁 ‘암호 입력’을 보조 문장으로 넣을 건 또 뭐란 말입니까.
무엇보다 이 팝업의 가장 큰 문제는 버튼이 2개라는 겁니다. 전형적인 취소/command 형태를 취하고 있는데 문제는 이 팝업이 앱 실행과 함께 번개처럼 올라왔다는 거예요. 그리고 이 팝업의 밑장, 백그라운드 화면에는 이미 암호 입력 키패드가 표시되고 있죠.
사용자는 왼쪽 ‘취소’ 버튼을 눌러도 암호 입력 키패드, ‘오른쪽 ‘암호 입력’ 버튼을 눌러도 동일하게 암호 입력 키패드로 떨어지게 됩니다.
모든 길은 로마로 통하고, 사랑은 돌아오는 거고, 둘 중에 하나를 골라도 그냥 yes or yes가 되는 세상 이치는 알겠습니다만 하루에도 수십 번 이 팝업을 보면서 ‘아아… 도대체 무슨 연유로….?’라고 생각하곤 했어요.
애초에 암호 입력 화면에 이미 들어와 있는데 그 위에 오른쪽 버튼 ‘암호 입력’ 버튼을 만든 것이 이 모든 괴랄함의 시작이었을지도 모르겠습니다. 펀쿨섹좌 풍이 유행이라지만, ‘암호 입력을 누르면 암호 입력이 있더라도 암호 입력하겠다는 의사라고 볼 수 없지만은 않지 않겠습니까?’ 이런 느낌의 쓸데없는 2 버튼 팝업 사용은 서비스를 신뢰할 수 없게 합니다.
너 내가 뭐 누르든지 똑같은 거 보여줄 거잖아. 안 그래? 내게 묻는 것처럼 했지만, 사실 묻는 게 아니잖아?
사용자의 마음은 언짢아질 수밖에 없겠죠
LINE의 Face ID 로그인 실패: 취소의 대상이 모호하다
그렇다면 LINE은 이 문제를 어떻게 다뤘을까요? LINE 비밀번호 설정 상태에서 LINE 앱 실행→Face ID 인식→실패 시에 나오는 화면입니다. 마스크를 쓴 상태로 Face ID 인식 실패를 했을 때 밑장에 비밀번호 입력 키패드가 나오는 것까지는 카카오톡과 동일하지만, 2 버튼이 아닌 1 버튼 팝업으로 구성했습니다.
본문에는 에러·실패가 발생한 현상만 기술되어 있습니다. LINE에서는 1 버튼만 제공함으로써 사용자에게 골치 아픈 선택의 여지를 주지 않습니다. 이 상황은 명백히 오류 상황입니다. 이때 사용자가 할 수 있는 일은 이 팝업을 후딱 닫고, 밑에 깔린 키패드에서 비밀번호 후딱 넣고, 앱에 진입하는 것 말고는 없죠. 불필요한 고민을 줄인 세상 단순한 플로우입니다. 훨씬 개운하고 가벼워요.
그렇다고 아무 문제가 없느냐? 그렇진 않습니다. 저 팝업 버튼의 ‘취소’가 적절하지 않다고 생각합니다
1 버튼 팝업에는 보통 취소를 쓰지 않습니다. 1 버튼 팝업은 보통 에러의 통보, 사용자 행위로 인해 발생하는 중대한 사항에 대한 알림, 공지 등을 위해 사용됩니다. 이때 활용하는 버튼은 그 내용을 확인했다는 의사 표시를 하기 위해 ‘확인(OK)’인 경우가 대부분입니다.
“응 그래, 알았어”의 느낌으로 confirm을 쓰거나 “시끄러, 꺼져!”의 느낌인 close를 쓰려는 시도도 있지만, 둘 다 어색합니다. 그냥 그 어디쯤에 있는 하나마나한 소리인 OK를 많이 쓰죠.
그런데 이 팝업에서는 굳이 ‘취소’를 썼습니다. 만약 레이블의 의미에 따라 액션을 구현할 경우 취소 버튼을 누르면 앱이 꺼져야 합니다. 왜냐하면 취소는 사용자의 직전 행위에 대한 철회, 즉 사용자가 앱을 실행하려는 의사를 철회한 것이니까요. 그러나 제 손으로 앱 종료를 시킬 수는 없는 법이죠. (미쳤다고 들어온 손님을 내보낸단 말입니까!)
요컨대, 1 버튼 팝업을 제공하여 사용자의 다음 행동을 빠르게 유도한 것까지는 좋았지만, 버튼을 취소로 넣은 것이 다소 아쉽습니다. 카카오톡의 2 버튼 팝업의 ‘취소’버튼에도 동일한 문제가 있겠습니다. 물론 이 역시 네이티브 팝업이기 때문에 우리 앱에서 어떻게 할 수 없는 것이었겠죠.
아무튼 이 1버튼 팝업으로 인해 LINE을 쓸 때마다 ‘아이고 카카오톡 팝업보다 이게 낫네. 아이고 차라리 이게 낫네’ 하는 생각을 하곤 했습니다.
UX writing은 사용자 경험을 위해 무엇을 할 수 있는가?
이 문제가 어떻게 해결되었는지 궁금하실 것 같아 말씀드립니다. ios 13.6으로 업데이트되면서 모든 앱에서 해당 Face id 인식 실패 팝업이 보이지 않고 바로 각 앱에서 준비한 화면(비밀번호 입력)이 보이도록 처리되었습니다. 일시에. 한 방에. 문제 해결.
이 케이스를 보면서 저는 UX writing이 사용자 경험을 위해 무엇을 할 수 있는지, 어쩔 수 없이 개발 제약이 생긴 상황에서 어떤 역할을 할 수 있는지에 대해서 생각하게 되었습니다.
불시에 찾아온 급박한 사용 환경의 변화에서 개발이나 디자인을 빨리 수정하기 어려울 때 레이블이 그 시간을 버텨 줄 수 있습니다. 당장 플로우 문제나 버그를 해결하지 못한다 해도, 사용자가 납득할 만한 레이블을 제공함으로써 불편함을 줄여줄 수 있죠. 사용자가 느끼는 불편함을 조금 더 나은 정보로, 조금 더 이해되는 문장으로, 조금 더 적절한 버튼으로 UX writing이 달래주는 것입니다. (반대로 레이블을 제대로 쓰지 않아서 문제를 만드는 상황이 더 많습니다만)
근원적인 문제를 해결하기 위해 기획자가, 디자이너가, 개발자가 불철주야 뛰고 있을 때 사용자가 당황하지 않도록 상황을 설명해주거나, 사용자의 문제임을 인지하지 못하도록 말로 잠시 커버 쳐주는 사람. UX writer는 종종 그런 역할을 맡곤 합니다. 그렇게 사용자 경험 구축에 역할을 하는 거죠.
아, 물론 가끔은 다 필요 없고 ‘개발이 최고야’라고 생각하기도 합니다. ios의 업데이트 한 방으로 사용 경험의 확실한 개선 무엇.
요약
2 버튼 팝업은 필연적으로 왼쪽에 ‘취소’를 수반하게 됩니다. 사용자가 별일 안 했을 때(취소할 일이 딱히 없을 때)에는 2 버튼 팝업을 주고 그러지 맙시다. 사용자가 중대한 선택을 해야 할 경우에만 2 버튼을 줍시다.
1 버튼 팝업은 에러의 통보, 사용자 행위로 인해 발생하는 중대한 사항에 대한 알림, 공지 등을 위해 사용됩니다. 이 때 버튼은 영혼 없긴 해도 확인(OK)을 많이 씁니다. 다르게 보이려고 여기에 ‘닫기’ 쓰지 맙시다. ‘뭔지 모르겠지만 저리 가’라는 의미입니다.
급박한 상황, 어쩔 수 없는 상황은 UX label으로 사용자 경험이 어그러지는 것을 어느 정도 막을 수 있습니다. 그러나 근원적인 문제를 해결하지 않고 말로 커버치려는 태도는 정중히 사양하겠습니다.
함께 읽으면 좋은 글
