버튼만 읽는 **한 세상!
[Daily component] 버튼: 버튼을 위한 소소한 팁
개노답 삼형제 막내를 소개하기 전 빌드 업 차원으로 UI 핵심 컴포넌트인 버튼 텍스트의 특징, 버튼에 담긴 사용자 Voice에 대해서 이야기 해보려고 합니다. 이건 직전에 소개한 개노답 삼 형제 큰 형 '-하기'와 어쩐지 짠한 양아치 둘째 형 'confirm shaming'에 대한 보충 설명이기도 합니다.
'뭔 쓸데없는 소리를 하려고 하느냐! 어서 개노답 시리즈나 내놓으렷다!'하지 마시고 조금만 기다려 주세요.
제게 다 생각이 있습니다. (... 아니 사실은 없어요...)
전에도 말씀드렸지만, 이 시리즈는 생각나면 중간에 막 쓰는 것이기 때문에 선형적으로 읽지 않으셔도 됩니다. 그저 가벼운 마음으로 즐겁게 읽어주시길 언제나 바라고 있답니다.
버튼은 사용자의 의사 표현 수단
의도한 건 아니었지만 지난 몇 편의 글에서 버튼에 대해 중점적으로 다뤘습니다.
버튼(Button)은 사용자가 터치 한 번으로 행동할 수 있게 하고, 또 선택할 수 있게 하는 컴포넌트입니다. 개인적으로는 이 버튼이야말로 사용자와 디자이너가 모두 신경 쓰는 특별한 UI 요소가 아닐까 생각합니다. 위에서 말했듯 사용자 액션을 발현시키고, 화면과 화면을 이어 주고, 사용자가 우리 서비스를 더 구경하게 하고, 중요한 매출을 일으키는 결정적인 요소도 모두 버튼이니까요. 서비스 관계자들이 차근차근 쌓아온 노력이 하나로 응집되어 결실을 맺을 때, 그 방아쇠가 되는 게 바로 버튼 아니겠습니까?
결제 Bang! 1년 정기구독 Bang!
아니 이 버튼 말고. 여기다가 노력 응집시키지 말고.버튼은 또한 사용자의 의사 표현 수단이라는 측면에서 큰 의미를 갖습니다.
UX를 서비스와 사용자의 '상호 작용', 그 모든 측면이라고 정의한다고 볼 때, 서비스가 사용자에게 자기 표현을 할 수 있는 통로는 상당히 많은 반면, 사용자가 서비스에게 의사를 표할 방법은 버튼 외에는 그렇게 많지 않습니다.
서비스는 스플래시 화면부터 화려한 컬러, 세련된 레이아웃, 매혹적인 인터렉션, 유려한 텍스트로 자신을 표현하지만, 사용자가 할 수 있는 의사 표현라고는 버튼 두 개 중에서 하나를 선택하거나, 버튼이 하나밖에 없는 데 안 누르고 버티면서 불안한 눈동자로 X 버튼을 찾거나 하는 게 전부죠. 물론 앱 스토어에 무서운 리뷰 남기기, 고객센터에 전화해서 거세게 클레임 걸기, 어벙한 챗봇과 각자 하고 싶은 말 만하기(...) 등이 있을 수 있겠지만, 이런 것들은 아주 드물면서도 적극적인 의사 표현이기 때문에 예외로 둡시다.
아무튼 사용자는 버튼을 쿡 누르는 행위로 저장, 삭제, 나가기 등 일상적인 액션을 행하기도 하고, 앱 추적 거부, 알림 해제, 해지, 탈퇴까지 서비스에 중대한 영향을 미칠 수 있는 의사 결정을 실행하기도 합니다.
버튼 작성을 위한 소소한 팁 하나 - 구체적인 동사로 근미래를 지시할 것
위한 소소한 팁
이렇게 중요한 버튼 텍스트를 쓸 때에는 크게 두 가지를 주의해야 합니다.
첫째는 버튼 레이블에는 굉장히 구체적이고 정확한 동사를 사용해야 한다는 것입니다.
이제 이건 주니어 디자이너들도 다 아는 국룰이 되었을 만큼 보편적인 상식이 되었습니다. '취소/ 확인', '아니요/네'와 같은 동작성 없는 모호한 버튼은 절대 쓰지 않는다. 우유 물 탄 듯, 밀키스에 우유 탄 듯한 모호한 액션 워드를 쓸 경우 사용자가 버튼만 보고 빠르게 의사 결정을 할 수 없습니다. 이런 버튼을 쓰면 '아니 도대체 뭘 취소하고 뭘 확인한단 말이냐! 뭐가 아니요고, 뭐가 네라는 말이냐!'라는 반응이 곧잘 나오니까 성미 급한 사용자님을 자극하지 말도록 합시다.
혹시 '사용자가 버튼만 보고 의사 결정을 하다니 무슨 말이지?' 싶으신가요?
간단하게 아래 그림으로 설명해 볼게요. 이 대충 만든 이미지는 제가 팝업을 작성할 때 떠올리는 암묵적인 사용자의 스캐닝 패턴을 담고 있습니다.
슬프지만 이게 암묵적인 인식입니다. 운 좋으면 사용자가 타이틀은 읽고, 원래 본문은 거의 안 읽는 거고, 결국 버튼만 읽고 선택하더라... 이것이 writer에게 닥친 냉정한 현실인걸요.
물론 저희 writer들이 팝업 하나를 작성할 때에는 타이틀을 어떻게 뽑을까, 본문에 얼마만큼의 정보량을 담을까, 문장이 2 문장 이상으로 늘어지고 논지가 두 개가 되면 사용자가 혼란스러워할 것이다, 숫자를 2개 이상 넣으면 그 순간부터 이 사람이 생각하는 걸 멈춘다, 지금 이 내용을 이 팝업으로 알려 줄 게 아니라 앞 화면에 먼저 인지시켰어야 자연스럽다, 이 팝업 건드리지 말고 앞 화면에 공간 남는지 좀 보자 등등 금이야 옥이야 문장을 다듬고 가꿔서 기획자님께 팝업 문구를 전달하지만, 저희도 사람들이 팝업 본문 긴 거 안 읽는 거 다 알아요.
왜냐면 저도 안 읽거든요...(야...)
(참고로 Google도 사람들이 본문은 안 읽다고 생각하더라구요. 그래서 팝업에선 타이틀과 버튼으로 승부를 보라고 가이드하고 있습니다. 이쯤되면 본문 안 읽는건 인류 보편 행동이라고 해도 될 것 같네요.)
아무튼! 그렇기 때문에 더더욱 버튼 텍스트를 작성할 때에는 굉장히 명확한 동사를 사용해야 합니다.
사실 '-하기'를 붙이느냐 안 붙이느냐 보다 훨씬 중요한 것이 어근의 선택, 동사를 뭘 쓸 것이냐입니다. 위 이미지의 버튼 '확인', '삭제' 중에 영양가 있는 쪽은 단연 구체적인 동사인 후자입니다. 그리고 그 동사로 근미래, 즉 눌렀을 때 바로 발생할 것 같은 상황을 지시해야 합니다. 저 버튼을 누르면 바로 삭제가 이루어질 것이다라는 확신이 빡! 들게 쓰시면 됩니다. 이 모든 플로우를 마친 후 먼 훗날 사용자가 얻게 될 최종 이익이나 행복한 결과 따윈 필요 없어요. 직접적이고 확실한, 다음 화면에서의 결과만 지시해 주세요.
실무에서 종종 만나는 삭제 관련 사례를 하나 소개해 보겠습니다.
기획자분들이 자주 문의하시는 케이스 중에 하나가 삭제 플로우에서 바로 삭제되는 게 아니라 삭제할 수 있는 페이지로 보내는 버튼을 뭘 써야 하냐는 것이지요. '삭제'라고 버튼을 쓰면 사용자가 불안해할 거다, 누르면 바로 삭제될 것 같아서(사실은 일단 다른 데로 가는데 말이죠) 그래서 버튼을 안 누를 것 같다, 뭐 이런 고민을 많이들 하십니다. 중요한 고민입니다. 버튼이 핍진하게 직후의 상황을 지시하지 못하면 실제로 불안감이 높아져서 버튼 클릭률이 매우 낮아집니다.
이런 케이스를 푸는 방법은 여러 가지가 있지만, 이럴 때 저는 보통 '~하러 가기' 같은 문형을 씁니다. 디자인팀에서 버튼 가로길이만 허락해 주시면 오해의 소지가 거의 없는 표현이거든요. 물론 독일어나, 러시아어 이런 언어들은 엄청 길기 때문에 그런 언어들은 다국어 PM 님들이 별도로 조치를 주시지만, 아무튼 기획자의 걱정을 간단하게 해결해주는 소소한 문형으로 이런 게 있다~하고 소개드립니다.
다른 더 좋은 방법이 있다면 편하게 그걸 써주세요. 사용자에게 정확한 상황을 예고할 수 있다면 뭐든 좋습니다.
한국 사례만 보면 서운해하실 거죠?
이 바닥에서 아주 유명한 Google의 버튼 개선 사례를 한 번 봅시다.
UX writing을 요술 방망이로 묘사할 때 자주 인용되는 Google 호텔 예약 케이스Google이 UX writing 성과로 자주 회자되는 호텔 예약 화면 버튼입니다. 원래 Book a room(숙박 예약)이라고 되어 있던 버튼을 Check availability(숙박 가능 여부 확인)으로 바꿨더니 사용자들이 17%나 늘었다더라! UX writing만 잘해도 이렇게 사용률이 높아집니다! 광 팔 때 자주 쓰는 케이스입니다.
바로 위에서 설명한 삭제 하러 가기랑 비슷한 상황인 거 눈치채셨겠죠? : )
사실 원래부터 저 버튼 누르면 바로 예약 플로우 안 타고 당연히 예약이 되는지 안되는지 확인부터 하게 합니다. 누구나 Book a room을 누르면 바로 덜컥 예약되지 않는다는 걸 머리로는 알고 있지만, 세상에 다양한 사이트와 예약 플로우가 있으니, 최악의 경우 이놈들이 나를 진짜 예약 화면으로 보내버릴 수도 있다는 두려움과 불안이 사용자의 마음에 자리하고 있습니다. 그런 사용자에게 이 버튼 레이블은 안전하다는 확신을 주지 못했습니다. 버튼이 바로 다음에 오는 화면을 정확하게 지시하지 못해서 사용자를 불안하게 만들었기 때문에, 결과적으로 이 서비스는 그동안 17%나 되는 사용자를 잃어버린 것이죠. 불안감을 낮춰주는 형태로 레이블을 고치니까 당연히 그만큼의 사용률이 회복된 것이고요.
제가 아무리 UX writing을 홍보하고 싶어 하는 자이긴 하지만, 이 케이스를 개선, 혁신, UX writing의 빛나는 효과, 말로써 지표를 상승시킨 대표적 사례 그런 거라고 선전하고 싶진 않아요. 오히려 반대로 UX writing을 제대로 못하면 서비스 지표가 한 방에 훅 간다를 보여주는 케이스라고 말하고 싶습니다.
여러분의 서비스도 마찬가지입니다. 만약 현재 UI text가 참혹한 수준이라면 정상적으로 고치기만 해도 사용률이 적잖이 올라갈 겁니다. 그렇지만 여러분 대부분은 예의 바르고 명석하며, 훌륭한 한국어 실력을 갖춘 네이티브 디자이너이실 것이라 사료되므로(굽신굽신), 여러분들이 쓰신 텍스트가 개막장일 확률은 매우 낮을 겁니다. 그럼 UX writing 컨설팅을 한다고 해도 빛나는 효과를 얻을 수는 없을 것 같아요. 그건 여러분이 본능적으로 웬만큼 잘 해놓으셔서 그래요.
꿀 같은 문장, 번지르르한 유머, 촌철살인 같은 문구 하나로 사용자를 더 끌어올 거라는 UX writing에 대한 기대는 부담스러우니까 정중히 사양하겠습니다. 다만 UI text를 잘 못 쓰면 그동안 갖고 있던 사용자, 또는 우리가 가질 뻔했던 잠재적 고객을 왜인지도 모르고 잃어버리게 될 거라는 건 이 자리에서 확실하게 말씀드릴 수 있습니다. UX writing은 사치재가 아니라 필수재니까요.
버튼 작성을 위한 소소한 팁 둘 - 사용자의 보이스를 잊지 말 것
두 번째로 주의해야 할 점은 버튼의 보이스, 즉 사용자의 보이스를 조심조심 다뤄야 한다는 것입니다.
지난 글에서 쓴 거 재탕할게요. 사골도 두 번은 우리니까 봐줘요.이전 글에서 언급한 이야기를 여기에서 다시 꺼내보자면, 상단은 서비스의 영역, 하단 버튼 영역은 사용자의 영역입니다. 버튼은 온전히 사용자의 공간이기 때문에 여기에 보이스와 톤이 있다면 그것은 사용자의 것일 수밖에 없습니다.
물론 영어든 한국어든 일반적인 스타일의 버튼에서는 사용자의 보이스를 찾기가 다소 어렵습니다.
아래에서 클럽하우스의 핵심 버튼 Leave quietly를 예로 설명해 보겠습니다.
제 주변에 이 버튼을 좋아하는 사람이 그렇게 많았더랬습니다. 이제 누구도 클럽하우스를 안 하는 거 같지만...같은 팀 영어 writer분들께 이 버튼의 톤이나 보이스는 네이티브에게 어떻게 받아들여지느냐고 물어봤어요. Imperative 형태가 흔히 명령형으로 번역되는 경우가 많지만, 이런 맥락에서는 꼭 명령을 의미하는 것이 아니라고 하시더라고요. 영알못인 저는 '혹시 이게 명령으로 느껴지려나...?' 싶었거든요.
동료분들의 의견으로는 영어 버튼에서의 Imperative 형은 훨씬 더 중립적이고 건조한, 일종의 기능적인 레이블에 가깝게 느껴진다고 하셨어요. 좀 더 쉽게 설명하자면 사용자가 이 버튼을 봤을 때에는 '조용히 퇴장'과 같은 기능적인 레이블로 인식하지, '시스템 네 이놈! 어서 나를 소리 없이 여기서 빠져나가게 하지 못할까!'라고 생각하진 않는다는 것이죠. 그래서 만약 한국어로 이 버튼을 번역하면 '조용히 나가기' '살그머니 퇴장' 같이 서술성 명사로 건조하게 표현될 가능성이 높습니다.
실제로 현재 한국 서비스 대부분의 버튼 레이블들도 이런 형태입니다. 중립적인 형태로 정보만 빠르게 꽂아주면 사용자가 스윽 스캔하고, 선택하고, 다음으로 넘어가는 거죠. 사용자가 머뭇거리거나 망설이지 않도록 그 무엇도 섞지 않으면 의사 결정 속도가 엄청 올라갑니다. 다르게 느끼거나 생각할 여지가 거의 없으니까요.
그런데 버튼에 뭘 섞으면, 그러니까 버튼에 사용자 보이스를 담으면 그때부터는 일이 약간 복잡해질 수 있겠습니다. 나쁘다는 게 아니라 복잡해진다는 거죠.(다음 글에서 물론 좋지 않은 사례를 제시할 거지만)
특히 눈여겨보아야 할 것은 버튼에서의 '-하기'와 '**'체의 사용입니다.
그건 다음 시간에...!
오늘의 요약
버튼은 사용자가 터치 한 번으로 행동을 할 수 있게 하고, 또 선택할 수 있게 하는 중요한 컴포넌트입니다. 무엇보다 사용자의 의사 표현 수단으로써 중요한 역할을 합니다.
버튼 텍스트는 반드시 구체적인 동사로 작성되어야 합니다. 취소, 확인, 네, 아니요 같은 모호한 표현은 지양하고 구체적인 액션 워드를 사용해 주세요. 또한 버튼 동사는 근미래, 즉 버튼을 누른 직후에 일어날 일을 지시해야 합니다. 몇 단계 뒤에 있을 일, 먼 훗날의 장밋빛 미래를 버튼으로 선전하지 말아 주세요. 사용자가 판단 기준을 잡지 못해서 버튼을 누르지 못하고 망설이게 됩니다.
버튼은 온전히 사용자의 영역이기에 사용자의 목소리가 드러날 수도 있습니다. 한국어 버튼의 가장 보편적인 형태인 서술성 명사형을 쓰면 사용자의 목소리가 거의 드러나지 않는, 건조하고 중립적인 형태가 되기 때문에 해당 버튼은 컨트롤러로써 기능하게 됩니다.
UX writing을 잘하는 것만으로 사용자를 엄청 끌어 올 수는 없지만, 텍스트를 잘못 써서 잘 쓰던 사용자를 서비스 밖으로 쫓아내는 건 가능합니다. UI에 있어서 UX writing은 사치재가 아니라 필수재라는 사실을 잊지 말아 주셔요.
오늘의 사건 사고 : 사실은 일요일에 카페에 앉아 5시간 정도 글을 썼는데 모두 날아갔습니다. 오랜만에 억장이 무너졌어요. 거의 다 썼었는데.... 아이고.
그래서 오늘 글의 텐션이 좀 낮습니다. 처음 쓴 글엔 쌉소리와 드립이 가득했는데, 어째 기억을 더듬어 다시 쓴 글은 재미가 별로 없더라고요. 정작 하고 싶었던 이야기, 버튼에서의 '-하기'와 '-해요'체 사용에 대해서는 다음 글에서 이어 가겠습니다. 애매한 지점에서 끊어서 죄송해요!
