UX 라이팅

화면의 말도 디자인이다

앱과 웹 서비스의 화면에 들어가는 짧은 글을 쓰고 다듬는 일을 UX 라이팅(UX writing)이라고 부른다. 버튼의 이름, 입력 칸의 라벨과 도움말, 오류 메시지, 아무것도 없을 때 보이는 문장, 확인을 묻는 대화상자, 휴대폰에 뜨는 알림이 모두 여기에 든다. 이런 짧은 글을 따로 마이크로카피(Microcopy)라고도 한다. 광고 문구가 사람을 서비스로 데려오는 글이라면, UX 라이팅은 이미 들어온 사람이 길을 잃지 않게 하는 글이다.

화면의 글을 쓸 때 가장 먼저 받아들일 전제는 사람들은 화면의 글을 읽지 않고 훑는다는 것이다. 손님은 책을 찾으러 왔지 안내문을 읽으러 오지 않았다. 버튼의 첫 두세 글자, 제목의 첫 어절, 빨간 상자의 첫 줄만 보고 다음 행동을 정한다. 그래서 UX 라이팅의 기술은 대부분 "훑어도 알 수 있게"로 모인다. 짧게, 앞에 핵심을, 같은 것은 같은 이름으로, 다음에 할 일을 분명하게.

또 하나의 전제는 글이 화면 구성과 따로 놀 수 없다는 것이다. 버튼의 폭은 문구의 길이를, 알림이 잘리는 자리는 문장의 순서를 정한다. 거꾸로 문구를 먼저 써 보면 화면에 빠진 상태(재고 없음, 기한 지남)가 드러나기도 한다. 7장의 종이 프로토타입에도 "가짜 글(로렘 입숨)" 대신 실제 문구를 적어 넣는 이유다.

버튼은 동사로

버튼의 이름은 누르면 일어나는 일이다. 그래서 버튼 문구는 행동을 나타내는 말, 곧 동사나 동사에서 온 말("맡아 두기", "다른 책방 보기")로 쓰는 것이 원칙이다. 한국어 화면에서는 "맡아 두기"처럼 "-기"로 끝나는 명사형이나 "취소", "저장" 같은 한자어 명사를 버튼에 많이 쓰는데, 어느 쪽이든 그 말을 읽고 무슨 일이 일어날지 알 수 있으면 된다. 문제는 "확인", "예", "OK"처럼 무엇을 하는지 말하지 않는 버튼이다.

이런 버튼이 가장 위험한 곳이 확인 대화상자(Confirmation dialog)다. 되돌리기 어려운 일을 하기 직전에 한 번 더 묻는 상자인데, 사람들은 대화상자가 뜨면 질문을 읽지 않고 버튼부터 누르는 일이 많다. 아래 대화상자의 본문은 가려져 있다. 버튼만 보고 "맡아 둔 것을 그대로 두는" 쪽을 눌러 본다.

"하는 일"로 쓴 버튼은 본문을 가려도 뜻이 통한다. 버튼 이름이 스스로 설명하기 때문이다. 주요 플랫폼의 디자인 지침도 같은 방향을 권한다. 애플의 Human Interface Guidelines와 구글의 Material Design은 경고·대화상자의 버튼에 "확인"이나 "예" 대신 그 버튼이 하는 일을 적으라고 안내한다. 취소 대화상자에서는 특히 "취소"라는 말을 버튼에 쓰지 않는다. 손님이 하려는 일 자체가 취소라서, 대화상자를 닫는 "취소"와 겹친다. 닫는 쪽은 "계속 맡아 두기", "돌아가기"처럼 남는 상태를 말해 준다.

버튼 문구를 고를 때 따져 볼 것은 세 가지다. 첫째, 버튼만 읽고 결과를 알 수 있는가. 둘째, 같은 일을 하는 버튼은 화면마다 같은 이름인가("맡아 두기"가 어떤 화면에서는 "예약", 다른 화면에서는 "찜"이 되면 다른 기능으로 읽힌다. 8장에서 손님들이 "맡아 두기"와 "찜하기"를 헷갈린 것과 같은 일이다). 셋째, 되돌릴 수 없는 일이면 그 사실을 버튼 근처에 적었는가. 확인 대화상자는 되돌릴 수 없는 일에만 쓰고, 되돌릴 수 있는 일은 묻지 않고 실행한 뒤 "되돌리기"를 주는 편이 손님의 시간을 아낀다(5장).

오류 메시지: 무엇이, 왜, 어떻게

오류 메시지는 손님이 가장 곤란한 순간에 읽는 글이다. 그래서 가장 정성을 들여야 하는데, 실제로는 개발 중에 개발자가 임시로 넣은 문장이 그대로 남는 일이 흔하다. "요청 실패(code 409)"가 그런 예다. 409는 웹 서버가 "요청이 지금 상태와 충돌한다"는 뜻으로 돌려주는 번호(HTTP 상태 코드)인데, 이 서비스에서는 "다른 손님이 방금 그 책을 먼저 맡았다"는 뜻이었다. 손님에게는 아무 뜻도 없는 숫자다.

좋은 오류 메시지는 세 가지를 말한다. 무엇이 일어났는가(맡아 두지 못했다), 왜 그런가(다른 손님이 먼저 맡았고, 그 책은 한 권뿐이다), 이제 어떻게 하면 되는가(다른 책방에서 찾기). 제이콥 닐슨(Jakob Nielsen)의 사용성 휴리스틱(1994년 판) 아홉째 항목 "사용자가 오류를 알아보고, 진단하고, 회복하도록 도우라"도 같은 내용이다. 웹 접근성 지침 WCAG 2.2도 입력 오류가 생기면 무엇이 잘못됐는지 글로 알리고(성공 기준 3.3.1 오류 식별, A 수준), 고칠 방법을 알 수 있으면 그것도 알려 주라고(3.3.3 오류 수정 제안, AA 수준) 요구한다.

세 요소를 모두 넣으면 글이 길어진다. 그래도 오류 메시지에서는 짧은 것보다 분명한 것이 먼저다. 손님은 이미 멈춰 서서 읽을 준비가 되어 있다. 대신 첫 문장은 짧게, 무엇이 일어났는지만 쓴다. 이유는 둘째 문장에, 다음 행동은 글이 아니라 버튼으로 준다. 버튼이 있으면 "다른 책방에서 찾아 주세요" 같은 지시문은 지워도 된다.

오류 메시지에서 피할 말투도 있다. "잘못 입력하셨습니다", "올바르지 않은 번호입니다"처럼 손님을 탓하는 말, "치명적 오류", "실패"처럼 겁주는 말, "알 수 없는 오류가 발생했습니다"처럼 아무것도 알려 주지 않는 말이다. 사실만 말한다. "인증 번호가 맞지 않아요"는 탓하지 않고도 무엇이 틀렸는지 알려 준다. 또 오류는 생긴 곳 가까이에 보여 준다. 화면 맨 위에 모아 둔 오류는 휴대폰에서 보이지 않는다. 입력 칸의 오류를 어디에 어떻게 보여 줄지는 WebBook 9장에서 다룬다.

빈 상태: 막다른 길을 길로

보여 줄 내용이 없을 때의 화면을 빈 상태(Empty state)라고 한다. 검색 결과가 없을 때, 처음 가입해 맡긴 책이 하나도 없을 때, 오늘 들어온 새 책이 없을 때다. 시안에서는 늘 내용이 가득 찬 화면만 그리기 때문에 빈 상태는 잊히기 쉽고, 결국 "결과 없음" 한 줄로 남는다. 그런데 손님에게 빈 화면은 막다른 길이다. 무엇이 없는지, 왜 없는지, 이제 어디로 가면 되는지 말해 주지 않으면 손님은 앱을 닫는다.

검색 결과의 빈 상태는 특히 중요하다. 결과가 없는 이유가 "정말 없어서"인지 "찾는 방법이 달라서"인지 구별해 줄 수 있기 때문이다. 아래에서 검색어를 바꾸며 "결과 없음"과 고친 빈 상태를 비교한다. 검색어를 문장에 끼워 넣을 때 생기는 한국어만의 문제도 함께 본다.

"‘작은아씨들’은(는) 없어요"처럼 괄호로 두 조사를 다 적는 문장은 개발하기 쉽지만 읽기에는 걸린다. 한국어의 조사는 앞말의 받침에 따라 은/는, 이/가, 을/를, 와/과, 으로/로처럼 바뀐다. 사람 이름, 책 제목, 책방 이름처럼 문장에 끼워 넣는 말이 바뀌는 곳에는 받침을 보고 조사를 고르는 코드를 넣거나, 조사가 필요 없게 문장을 바꾼다. "검색어: 작은아씨들 · 네 책방에 없어요"처럼 끼워 넣는 말을 문장 밖으로 빼는 방법도 있다. 한글 음절은 유니코드에서 규칙적으로 배열되어 있어서, 음절 번호로 받침이 있는지를 계산할 수 있다.

중요한 말을 앞에

화면의 글은 잘린다. 휴대폰 잠금 화면의 알림은 한두 줄에서, 목록의 제목은 한 줄에서, 문자 미리보기는 몇십 자에서 끝나고 "…"이 붙는다. 사람들은 잘린 앞부분만 보고 열지 말지를 정한다. 그러니 앞부분에 인사말이나 서비스 이름이 오면, 정작 손님이 알아야 할 말은 잘린 뒤에 숨는다. 신문 기사가 가장 중요한 사실을 첫 문장에 두는 것과 같은 원리다.

아래는 책이 준비됐다는 알림이다. 알림 상자의 오른쪽 끝을 끌어 폭을 바꾸고, 문장 순서와 보이는 줄 수를 바꿔 본다. 손님이 알아야 할 것은 세 가지다. 어떤 책인지, 어느 책방인지, 언제까지인지.

앞에 놓을 말을 고르는 기준은 "이 글만 보고 손님이 무엇을 결정하는가"다. 알림이라면 열어 볼지, 오늘 찾으러 갈지를 정한다. 그러니 책 제목, 책방, 기한이 앞에 와야 한다. 목록의 항목 제목이라면 서로를 구별하는 말이 앞에 와야 한다. "맡아 두기 요청 – 작은 아씨들", "맡아 두기 요청 – 어린 왕자"처럼 같은 말로 시작하는 목록은 앞부분이 모두 같아 훑을 수 없다. "작은 아씨들 · 요청됨"이 낫다.

높임과 어조: 한 서비스, 한 목소리

한국어로 화면의 글을 쓸 때 영어에는 없는 결정이 하나 더 있다. 듣는 사람을 얼마나 높일지를 문장 끝(종결 어미)으로 표시해야 한다. 이것을 상대 높임법(Speech level, 청자 높임)이라고 한다. 학교 문법에서는 보통 여섯 단계로 나눈다.

어느 단계를 고를지는 서비스의 목소리와 손님에 따라 정할 일이고, 정답은 없다. 정할 것은 하나로 맞추는 것이다. 한 화면 안에서 "요청했어요"와 "취소되었습니다"가 섞이면 두 사람이 번갈아 말하는 것처럼 들린다. 여러 사람이 각자 문구를 쓰는 서비스에서 이 일은 아주 흔하다. "맡아 두기"는 네 책방 주인이 각자 안내문을 써 넣으면서 해요체, 합니다체, 해라체, 반말이 한 화면에 모였다.

문장이 아닌 글에는 다른 규칙을 둔다. 버튼과 메뉴, 탭, 제목처럼 짧은 이름은 "맡아 두기", "맡긴 책", "책방 정보"처럼 명사나 "-기" 명사형으로 쓰는 것이 흔한 관례이고, 이것은 말투가 섞인 것이 아니다. "기한 경과 시 자동 취소됨"처럼 "-음/-함/-됨"으로 끝내는 개조식은 보고서와 공문의 말투라, 손님에게 하는 문장으로는 딱딱하다. 아래 점검기에 문구를 넣으면 문장마다 끝을 보고 말투를 가려낸다.

점검기가 노란색으로 따로 표시하는 표현이 있다. 하나는 "주문하신 책이 나오셨습니다"처럼 높일 사람이 아닌 사물을 높이는 말이다. "-시-"는 문장의 주어를 높이는 말인데(주체 높임), 주어가 책이면 책을 높이는 셈이 된다. 손님을 높이려는 마음이 넘친 것이지만, "주문하신 책이 나왔어요"로 충분하다. "주문하신"의 "-시-"는 주문한 사람이 손님이라 맞다. 다른 하나는 "잠시만 기다리실게요" 같은 말이다. "-ㄹ게요"는 말하는 사람이 자기가 하겠다고 약속할 때 쓰는 어미라, 손님에게 무언가를 하라고 할 때 붙이면 어색하다. "잠시만 기다려 주세요"가 맞다. 둘 다 서비스 현장에서 널리 들리지만, 어법에 맞지 않는다는 지적을 오래 받아 온 표현이다.

문구의 길이와 좁은 화면

문구는 화면의 폭 안에 들어가야 한다. 시안의 버튼은 디자이너의 화면 폭과 기본 글자 크기에서만 맞춰 그려진다. 그런데 손님의 휴대폰은 더 좁을 수 있고, 손님이 글자 크기를 키워 쓰고 있을 수 있다. 서비스를 다른 언어로 옮기면 같은 뜻의 문구가 훨씬 길어지기도 한다. WCAG 2.2의 성공 기준 1.4.4(글자 크기 조절, AA 수준)는 보조 기술 없이 글자를 200%까지 키워도 내용과 기능을 잃지 않게 하라고 요구한다. 버튼 문구가 말줄임표로 잘려 "다른 책방…"이 되면 기능을 잃은 것이다.

아래는 결과 화면의 아래쪽(행동 버튼 두 개와 탭 막대)이다. 가상 화면의 오른쪽 끝을 끌어 폭을 바꾸고, 글자 크기와 언어, 넘칠 때의 처리를 바꿔 본다.

세 가지 처리에는 각자 대가가 있다. 말줄임은 화면의 모양을 지키지만 글을 잃는다. 버튼 이름에는 쓰지 않는 것이 좋다. 줄바꿈은 글을 지키지만 버튼의 높이가 들쭉날쭉해진다. 세로로 쌓기는 가장 튼튼하지만 화면 아래를 더 많이 차지한다. 그래서 흔히 쓰는 방법은, 넓을 때는 나란히 두다가 문구가 들어가지 않으면 세로로 쌓도록 짜는 것이다. 디자이너가 할 일은 이 규칙을 시안에 적어 두고, 가장 좁은 폭(WebBook 2장에서 정한 320px)과 가장 큰 글자에서 가장 긴 문구로 한 번 그려 보는 것이다. 문구를 짧게 고치는 것은 그다음이다. 짧은 문구는 좋지만, 짧게 만들다가 뜻을 잃으면 안 된다.

문구 원칙과 문구 표

서비스의 문구는 한 사람이 다 쓰지 않는다. 디자이너, 개발자, 주인, 나중에 들어올 사람이 각자 쓴다. 그래서 문구를 하나하나 고치는 것만큼, 누가 써도 같은 목소리가 나오게 하는 장치가 중요하다. 흔히 쓰는 장치는 두 가지다. 하나는 짧은 문구 원칙이다. 다섯 줄 안팎으로, 외울 수 있을 만큼 짧아야 실제로 쓰인다. 다른 하나는 문구 표다. 화면과 상황마다 실제 문구를 한 칸씩 적은 표로, 개발자는 이 표의 문구를 그대로 가져다 쓰고, 문구를 바꿀 때는 표부터 고친다. 용어 목록(쓰는 말과 쓰지 않는 말)도 함께 둔다.

문구 표에는 문구만이 아니라 그 문구가 나오는 조건과 끼워 넣는 값(책 제목, 책방 이름, 날짜)을 함께 적는다. "{책 제목}" 같은 자리에 무엇이 들어오는지, 조사를 어떻게 고르는지, 가장 긴 값이 들어오면 어떻게 되는지를 적어 두어야 개발자가 같은 문장을 만든다. 이렇게 정한 문구와 용어는 다음 장의 디자인 시스템이 컴포넌트와 함께 관리하는 대상이 된다.

서윤의 봄 서비스 노트