brunch

매거진 UX Writing

You can make anything
by writing

C.S.Lewis

by Joo Jun Aug 30. 2020

UI text가 정확하다는 것의 의미

UX writing의 제 1원칙, 정확성 (2)

정확성의 소원칙 4가지 중 나머지 2가지를 이번 글에서 이어 씁니다.



포괄적으로 쓰지 않는다.


해묵은 딥빡 포인트


'아이디 또는 비밀번호를 잘못 입력하셨습니다'는 하루에서 수만, 어쩌면 수십만의 사람을 힘들게 하는 에러 메시지일 수 있습니다. 딥빡을 불러오는 이 해묵은 메시지에 대해서는 저도 왜 이렇게 밖에 쓸 수 없는지 알만한 사람에게 물어보지를 못해서, 추측만 해볼 뿐입니다. 

아마도 보안 때문이겠죠. 아이디, 비밀번호 중에 어떤 것이 틀렸는지 명확하게 밝힌다면 그만큼 외부의 해킹이나 공격에 취약해질 수 있기 때문이 아닐까...  짬밥에 의거하여 막연하게 생각해 봅니다. 


위 에러 메시지는 어쩐지 이유가 있을 것 같아서 그렇다고 쳐도, 사실 이유 없이 모호하게 제공되는 메시지가 꽤나 많습니다. UX writer로 일하면서 제가 가장 많이 듣는 코멘트 중엔 이런 게 있습니다.


나중을 생각해서 포괄적으로 사용할 수 있게 써주세요.
'에러가 발생했습니다.' 이거 어때요?


디자이너나 개발자의 입장에서 에러 메시지는 적으면 적을수록 좋겠죠. 관리 차원에서 하나의 메시지를 아무 때나 불러다 쓸 수 있으면 편하기야 할 겁니다.

그렇지만 과연 오류 상황에 사용자도 그렇게 생각할까요? 

필수 항목 입력이 빠졌을 때, 이메일을 입력해야 하는데 형식에 @가 빠졌을 때, 서버가 다운되어서 당장은 뭔가를 할 수 없을 때에도 모두 동일하게 '에러가 발생했습니다'를 뿌린다면 사용자가 그 문제를 해결하기는 쉽지 않을 겁니다. 

그렇게 결국 만드는 사람만 편하고, 쓰는 사람은 불편한 서비스가 탄생하게 되는 거죠. 

뿐만이 아닙니다. 앵무새처럼 무슨 문제만 생기면 '에러가 발생했습니다'만 보여주는 서비스를 보며 사용자가 이 서비스가 제대로 돌아가고 있다고 생각하기도 어렵겠죠.

 '와 이 서비스 참 정성 없다... 대충이네...' 이런 인상을 받을 확률이 높습니다.


저는 일하면서 이런 말도 자주 듣곤 했습니다


나중에 스펙이 확장될 수 있으니까 그거 고려해서 써주세요. 
일단 기능명 밝히지 않고 다 커버할 수 있게 '기능이 실행되었습니다' 같은 거?


이런 말을 들을 때에는 '백 년도 못 사는 중생들이 천년을 걱정하는구나... 허허허.' 같은 말을 남기고 흰 수염을 흩날리며 구름을 타고 멀리 사라지고 싶은 욕망이 솟구쳐 오릅니다. 


우리가 이 서비스의 이 기능을 내년 이맘때에도 담당하고 있을지는 아무도 모릅니다. 

사실 이 기능을 디자인하는 디자이너, 개발자 저까지 이 회사를 내년에 다니고 있을지도 모르는 상황이죠(물론 저는 회사 오래 다니고 싶습니다만... 굽신굽신) 

그런데 앞으로 스펙이 확장될 수 있으니까, 또는 변경될 수 있으니까 그 상황도 커버해줄 수 있는 그런 메시지를 적어달라고 요청하는 건 좀 아니다 싶습니다. 해당 서비스 개선 방향이 확정된 것도 아닌데, 벌써부터 미래를 고려해서 메시지를 써야 할까요? 현재의 사용성을 포기하면서까지?

성장기 어린이 겨울 점퍼 사듯 미리부터 큰 옷, 그러니까 미리부터 크게 포괄할 수 있는 메시지를 작성할 이유가 없습니다. 아시다시피 아이 옷은 딱 맞춰서 입혀야 예쁘다고요.


이런 식의 모호하고 포괄적인 형태로 작성해달라는 요청이 왜 디자인이나 개발이 아닌 writer 에게만 유독 몰리는가에 대해서 한 번 정도 생각해 본 적이 있습니다.

아마도 디자인이나 개발은 원하는 방식으로 움직이게 하기 위해서 타깃과 직접적인 연계성을 가지고 설계되어야 하지만, 텍스트는 굳이 그렇지 않아도 되지 않으니까?라고 잘못 생각하고 있기 때문이 아닐까요... 일단 이게 지금까지의 제 추측입니다.


또 처음부터 설계 시에 해당 케이스들이 분리될 거라는 것을 생각 못하고 기획, 개발, 디자인까지 다 나왔는데 알고 보니 케이스를 분기 쳐야 하는 것이 나중에 밝혀졌을 때, 세상 당황스럽고 귀찮은 상황이 발생했는데 릴리즈가 얼마 남지 않았을 때, 바로 그때 디자이너의 입에서 '일단 에러 상황을 다 포괄할 수 있는 메시지로 써주세요. 다음  phase 때  고칠게요.'와 같은 코멘트가 나오게 되는 것 같기도 해요. (그런 말 들을 때 제 표정은 이미 돌덩이)


이런 포괄적이고 모호한 메시지를 작성하지 않기 위해 제가 추천드리는 방법은 다음 두 가지입니다.


1. 주어는 정확한 기능명을 사용하고 서술어는 실질적인 의미를 가진 동사로 씁니다.
2. '또는', '혹은', '거나'와 같이 상황을 2개 이상 제시하는 접속사를 사용하지 않습니다.


이거 두 개만 잘해도 나도 모르게 포괄적이거나 모호한 표현을 쓰는 일을 방지할 수 있습니다. 


명확한 표현으로 정보를 설명한다.


이것에 대해서는 너무나 말하기 어렵지만, 말을 아니할 수 없습니다. 

일을 하다 보면 생각보다 표준어를 구사하지 못하는 사람, 그러니까 맞춤법을 틀리는 사람, 파워당당하게 비문을 쓰는 사람을 많이 만납니다. 

센스도 있고, 감각도 있고, 커뮤니케이션 스킬도 좋고 디자인도 잘하는데 

아아아... 글을 못쓰는 디자이너를 볼 때마다 마음이 무너집니다. 아이고 이 사람아...

내 맘은 그것이 아닌데, 내가 하고 싶은 말은 그것이 아닌데 그냥 그렇게 쓰게 되는 상황, 항상 일정에 쫓겨서 텍스트를 가장 마지막에 쓰게 되는 상황 참 많이 발생하겠지요. 개발에서 'QA 하다가 이거 이런 에러 상황이 있으니까 팝업 문구 빨리 하나 만들어 주세요!'라고 하면 머리가 하얘지면서 일단 뭐라도 써서 빨리 줘야겠기 때문에 아무 말 대잔치는 했는데 이게 맞는 건지 모르겠고...


일단 다음 두 가지 예시를 살펴보며 자주 발생하는 불명확한 표현 사용에 대해 알아봅시다.


A. Wifi 연결이 해지되었습니다.
B. Wi-Fi 연결이 해제되었습니다.


 A와 B 중에서 어떤 것이 정확한 레이블인지에 대해 다 아시리라 믿지만, 굳이 정답을 말하자면 B 가 정확한 쪽입니다. Wi-Fi가 바른 표기이고, '해지'는 서비스를 영구적으로 사용하지 않음, '해제'는 기능을 일시적으로 사용하지 않음을 의미하는 용어이므로 당연히 후자를 사용해야 합니다.

외국어 표기, 해지와 해제 , 정지와 중지 등의 헷갈리는 용어 등은 신문이든, 표준국어대사전(=네이버 사전)이든 검색해보면 바로 알 수 있습니다. 시간에 쫓긴다고 그냥 넘어가지 마시고 한 번만, 그니까 정말 한 번만! 네이버 맞춤법 검사기, 브런치 맞춤법 검사기를 한 번 돌려보고 개발에 메시지를 넘겨주세요.


A. % s가 응답하지 않습니다. 통화는 이 기기에서 이어집니다.
B. % s 기기에 파일을 보낼 수 없습니다. 현재 통화는 계속해서 진행할 수 있습니다.


조금 더 까다로운 문제입니다. 

분명히 둘 다 비문이거나 틀린 이야기를 하고 있는 것인 아닌데, 어느 쪽을 써야 할지 선택이 어려울 수 있습니다. 

A는 전통적인 개발 용어를 한국어로 번역한 번역투 문장이고 불필요한 지시사 '이'를 사용하고 있습니다. 내용상 파일은 못 보내고 통화는 계속할 수 있다는 의미인 것 같은데 굳이 지시사 '이'를 쓸 필요가 없죠(이 휴대폰 말고 다른 휴대폰을 쓸건 아니니까요).

B는 사용자를 주어로 고정하고(문장 내에서는 생략되었지만 맥락상 주어를 파악할 수 있습니다), 사용자 중심으로 서술했습니다. '대상이 응답을 하다'라는 표현보다는 사용자가 시도한 행위가 실패했라는 방향으로 기술하고, 실패에도 불구하고 사용자가 계속할 수 있는 행위는 무엇인지도 알려주었습니다. 주어가 다른 두 문장이 연이어 있는 A 보다는 B 가 흐름상 이해하기 쉽습니다.


좋은 문장을 쓰기 위해서는 꽤 오랜 시간의 훈련을 해야 합니다. 

다양한 케이스를 접해보고, 각 상황마다 사용자가 어떻게 판단할지, 어떤 표현을 쓰면 사용자가 빠르고 오해 없이 이해할 수 있을지 고민해야 합니다. 끊임없이 사용자의 언어 습관에 대해 관심을 갖고 발견해낸 패턴과 용어들을 연습해야 합니다. 해야 할 일이 많은 디자이너 입장에서는 이런 훈련을 꾸준히 해나간다는 것이 쉬운 일은 아닐 것입니다.

정확한 표현으로 텍스트를 작성하기 위해 제가 추천드리는 방법은 다음 세 가지입니다.


1. 확정 전에 네이버, 브런치 맞춤법 검사기를 한 번이라도 돌려보세요.
2. 어떤 표현이 더 사용자 친화적인지, 더 보편적인지 구분이 어려울 때에는 주요 일간지 신문기사에서 해당 용어들을 검색해 보세요. 사용 빈도 수가 높은 용어를 쓰시는 것을 권해드립니다.
3. 내가 무슨 말을 하고 있는지 정신이 혼미할 때에는 잠깐 30분이나 1시간쯤 써놓은 문장을 보지 않고 있다가 머리를 털털 털어내고 다시 읽어보길 바랍니다.
잠깐 쉬면 유체이탈이 되고 과거의 나를 냉정하게 깔 수(?) 있습니다. 자기 객관화가 뭐 별건가요.



오늘의 요약


정확하게 쓴다는 것은 모호하거나 포괄적으로 쓰지 않는다는 의미입니다. 먼 미래를 생각하지 말고 현재에 충실하게, 각 케이스에 딱 맞는 메시지를 따로 준비해 주세요. 귀찮다고 모호한 말로 퉁치기 없기로 해요. 우리.

정확하게 쓴다는 것은 상황을 가장 핍진하게 설명해 줄 수 있는 명확한 표현을 사용한다는 의미입니다. 어문 규정에 맞는 표준어 사용, 비문 지양은 물론이고, 사용자가 읽고 이해하기 쉬운 문형으로 서술하도록 합시다.

모르면 사전, 검색 포털, 맞춤법 검사기를 돌립시다. 당장 맞춤법 모르는 거 하나도 부끄럽지 않아요. 노력 안 해서 틀린 그대로 서비스 릴리즈 되는 게 더 부끄러운 일입니다. 서비스 이미지가 진짜 구려진다구요. 




덧1: '아이디 또는 비밀번호를 잘못 입력하셨습니다'에 대해 동료와 이야기하다가 이 메시지의 정체는 역시 보안때문이라는 점을 확인 받았습니다. 


The challenge with password resets is finding the right balance between security and usability. You need to give users enough information to know what’s going on when they initiate a password reset, but you risk playing right into a hacker’s hands if you give up too much.


Ideally, you would never confirm or deny the existence of an account with a given email or username.


Sometimes, you’ll come across an error message that looks something like this: “We couldn’t find a user with that email address.” If you use this method, then the absence of this message implicitly confirms the user account's existence.


이렇게 모호한 메시지를 올리는 것보다는 더 나은 방법들이 많이 있다는 것도 알게 되었어요. 

예를 들면 등록된 이메일로 바로 확인 메일 보내서 본인이 다시 패스워드를 설정하게하는 방법들 같은 것? 

자세한 내용은 여기!

매거진의 이전글 아시안 하이웨이같은 UI text
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari