brunch

매거진 UX Writing

라이킷 30 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Joo Jun Aug 16. 2020

마스크 시대의 취소 버튼(2)

LINE, 카카오톡의 Face ID 인식 실패 팝업

지난 글에서는 '취소'의 의미와 쓰임, 적용 시 주의점에 대해 이야기해 봤습니다.

이번 글에서는 그동안 제게 불편함을 줬던 어떤 '취소' 버튼이 얼마 전 바람직한 방향으로 제거되었기 때문에 기쁜 마음에 해당 케이스에 대해 이야기 나눠볼까 합니다.

오늘 이야기 나눌 주제는 LINE, 카카오톡 로그인 시 등장하는했던 Face ID 인식 오류 팝업, 그 팝업의 '취소' 버튼입니다.

하루 백번 겪는 실패: 마스크 시대 Face ID 로그인 실패

아이폰 사용자는 하루에 몇 번이나 휴대폰을 깨우고 잠금을 해제할까요? 본인이 얼마나 헤비 유저인지, 얼마나 많은 앱에 로그인 설정을 걸어 놓았는지에 따라 천차만별이겠지만, 저는 평균 100번 정도의 휴대폰 깨우기를 한다고 스크린 타임이 알려주었네요.

저는 Face ID를 설정해두고 잠금을 해제합니다. 아시다시피 Face ID는 너무나도 편하기 때문에 한 번 사용을 시작한 이후에는 그전의 상태로 돌아갈 수 없는, 그러니까 소금구이 먹다가 양념 구이로 넘어가면 다시 소금구이로 돌아갈 수 없는, 그런 강렬한 충성도를 갖게 하는 기능이죠. 그런데 이 Face ID 때문에 하루의 대부분을 마스크를 쓰고 생활했던 올 상반기, 저는 하루에도 수십 번, 아니 백번 넘게 실패를 겪을 수밖에 없었습니다.

네, 그래요. Face ID 인식 실패. 마스크를 쓰고 화면을 밀어 올리면, 부들부들 간질간질한 진동과 흔들흔들거리는 애니메이션을 느끼며 애플 특유의 한국어 로컬리제이션, 영 어색한 그 음슴체를 읽곤 했습니다.

(아오 개조식 글쓰기이시여...)

위로 쓸어 올려 Face ID 사용 또는 암호 입력

얼굴이 인식되지 않음

너무 많이 봐서 문구도 외울 지경

이 화면의 '취소' 버튼은 취소할 행위를 '위로 쓸어 올려 잠금을 해제하려 하는 의도'로 규정합니다. 즉, 잠금을 해제하려는 사용자의 의사를 철회한다고 보는 것이죠. 실제로 취소 버튼을 누르면 직전 화면인 잠금화면으로 다시 되돌아 갑니다.

여기까지는 문제가 없습니다. 실제로 직전에 사용가 수행한 행위가 있기 때문이죠.

그러나 개별 앱의 잠금을 해제할 때에는 다른 상황이 펼쳐집니다.

카카오톡 Face ID 로그인 실패: 무엇을 누르든 암호 입력을 보게 될 것이다.

LINE에 다니지만 카카오톡도 자주 쓰는지라 매번 Face ID로 잠금을 해제하면서 사용해 왔는데, 코로나 대폭발 이후 마스크를 생활화하면서 하루에서 수십 번 이 팝업을 보게 되었습니다.

Q1. 이 화면에 암호라는 단어가 몇 번이나 나오는지 쓰시오.

카카오톡 비밀번호 설정 상태에서 카카오톡 실행 > Face ID 인식 > 실패 시에 나오는 팝업입니다.

팝업 바디를 타이틀과 디스크립션으로 나눴습니다. 이 팝업 자체를 ios 네이티브 팝업에서 어느 정도 요소를 가져온 것 같은데, 아니 어쩌면 기존에 쓰던 OS 네이티브 팝업을 그대로 뿌렸을 수도 있겠습니다만

(카카오톡 말고 이런 스타일 쓰는 앱들이 몇 개 있더군요)

그렇다고 해서 뭐라고 안 할 수 없는 게... 아니, 이 팝업 레이블은 정말이지 너무 대충 썼습니다.

현재 상황인 '얼굴이 인식되지 않음'을 밝힌 것까진 좋아요. 2 버튼 팝업을 쓰려면 디스크립션에 뭔가 뭘 어떻게 할 건지 묻던지, 아니면 뭘 어떻게 하라고 디렉션을 주든지, 앞으로 어떻게 될 거라든지 정보를 더 제공하든지 그도 저도 아니면 아예 아무 말도 말든지... 덜렁 '암호 입력'을 보조 문장으로 넣을 건 또 뭐란 말입니까.

무엇보다 이 팝업의 가장 큰 문제는 버튼이 2개라는 겁니다.

전형적인 취소/command 형태를 취하고 있는데 문제는 이 팝업이 앱 실행과 함께 번개처럼 올라와 버렸고, 이 팝업의 밑장, 그러니까 백그라운드 화면에 이미 암호 입력 키패드가 표시되고 있다는 거죠.

사용자는 왼쪽 '취소' 버튼을 눌러도 암호 입력 키패드, '오른쪽 '암호 입력' 버튼을 눌러도 동일하게 암호 입력 키패드로 떨어지게 됩니다.

둘 중에 하나만 골라, '암호 입력' 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의 업데이트 한 방으로, 아오 진짜 사용 경험의 확실한 개선 무엇.