UX 라이팅

제품 안에 들어가는 말은 오랫동안 누구의 일도 아니었습니다. 디자이너는 시안에 "제목이 들어갈 자리" 라고 적어 넘겼고, 개발자는 코드를 쓰다가 그 자리를 채울 말을 즉석에서 지어냈습니다. 화면에서 일이 어긋나는 경우가 스무 가지인데 그것을 알리는 문구는 하나였습니다. 오류가 발생했으니 잠시 후 다시 시도해 달라는 문장이었습니다.

그 문장이 무슨 일을 하는지는 고객센터 쪽에서 드러났습니다. 파일을 못 올리겠다는 문의가 하루 스무 건씩 들어오는데, 담당자가 계정을 열어 보면 원인이 거의 같았습니다. 파일이 용량 한도를 넘은 것이었습니다. 화면이 파일 크기가 20MB를 넘어 올릴 수 없다고만 알려 줬으면 그 사람은 문의를 쓰는 대신 파일을 줄였을 것입니다. 문구 한 줄이 비어 있어서 하루 스무 번씩 사람 손이 대신 들어간 셈입니다.

말이 흩어지는 문제도 함께 있었습니다. 같은 것을 부르는 이름이 화면마다 달랐습니다. 가입 화면에서는 워크스페이스, 설정에서는 팀, 결제 화면에서는 조직이라고 적혀 있으면 사용자는 그 셋이 같은 것인지 확인하느라 멈춥니다. 화면마다 만든 사람과 만든 달이 달라서 생긴 일이고, 각자는 틀린 말을 쓰지 않았는데도 제품 전체로 보면 앞뒤가 맞지 않습니다.

디자인 축에서 이 용어는 무엇을 설계하는가 쪽에 놓입니다. 사용자가 제품을 쓰는 동안 겪는 것 전부를 묶어 사용자 경험이라 부르고, 그 경험을 이루는 재료가 여럿입니다. 내용을 어떻게 나누고 무엇이라 이름 붙일지 정하는 뼈대, 누르고 끌었을 때 제품이 어떻게 반응할지 정하는 동작, 크기와 색으로 무엇을 먼저 읽게 할지 정하는 화면이 그 재료입니다. UX 라이팅은 그중 말을 맡습니다. 뼈대는 메뉴 이름을 요구하고 동작은 진행 중임을 알리는 한 줄을 요구하므로, 문구는 이 셋과 떨어져 정해지지 않습니다.

UX 라이팅은 이 말들을 화면 부품과 같은 설계 대상으로 끌어올린 것입니다. 색과 간격을 미리 정해 두고 쓰듯 문구도 기준을 정해 두고 씁니다. 회사가 어느 정도 커지면 이 일만 맡는 UX 라이터 자리가 생기지만, 그 전까지는 디자이너와 기획자가 나눠 씁니다. 직함이 없다고 일이 없는 것은 아니고, 다만 기준 없이 매번 새로 지어내는 상태가 될 뿐입니다.

UX 라이팅 아래 묶인 용어는 세 갈래입니다. 무엇을 쓰는가(대상), 어떻게 쓰기로 정해 두었는가(기준), 다른 언어로 어떻게 넘기는가(확장)입니다. 앞의 갈래는 화면에서 눈에 보이는 것이고, 뒤의 둘은 그 문구를 만들어 내는 규칙과 그 규칙이 언어를 건널 때의 조건입니다.

대상은 다섯입니다. 가장 위에 마이크로카피가 있습니다. 버튼 위 한 단어, 입력 칸 아래 한 줄처럼 제품 곳곳에 박힌 짧은 문구 전부를 묶어 부르는 말이고, 나머지 넷은 그중 자주 문제가 되는 자리에 따로 이름을 붙인 것입니다.

1. 버튼 레이블 — 누르면 무슨 일이 벌어지는지 알려 주는 문구입니다. "확인" 은 무엇이 확인되는지 말해 주지 않습니다. 삭제 여부를 묻는 창에서는 "삭제" 라고 적는 편이 안전합니다. 결과를 동사로 적어 두면 사용자가 위의 설명을 다 읽지 않고 눌러도 벌어지는 일이 예상과 어긋나지 않습니다.
2. 오류 메시지 — 무엇이 잘못됐는지와 무엇을 하면 되는지가 둘 다 있어야 하는 문구입니다. 앞만 있고 뒤가 없으면 사람은 고객센터로 갑니다. 원인을 말하기 어려운 경우라도 다시 시도할지 다른 길로 갈지는 적어 둘 수 있습니다.
3. 빈 상태 문구 — 목록에 아무것도 없을 때 화면에 남는 말입니다. "문서가 없습니다" 는 사실만 알리고 끝납니다. 가입 직후 처음 마주하는 화면이 대개 여기라서, 첫 문서를 어떻게 만드는지를 적어 두면 이 자리가 안내 역할을 겸합니다.
4. 플레이스홀더 — 입력 칸에 흐리게 적어 둔 예시입니다. 입력을 시작하면 사라지기 때문에 여기에 형식 설명을 넣으면 정작 필요한 순간에 없습니다. 설명은 칸 밖에 두고 이 자리에는 예시만 둡니다.
5. 알림과 확인창에 들어가는 문구도 같은 갈래로 다룹니다. 알림은 지금 제품을 보고 있지 않은 사람에게 가는 말이라 무슨 일이 어디서 일어났는지가 한 줄 안에 다 들어 있어야 합니다. 확인창은 되돌릴 수 없는 동작을 묻는 자리라 무엇이 사라지는지를 문장 안에 적습니다. 문서 세 개가 영구 삭제된다고 적은 창과 정말 삭제하겠느냐고만 적은 창은 누르는 손의 확신이 다릅니다.

기준은 둘입니다. 문구를 쓸 때마다 매번 새로 판단하지 않도록 팀이 미리 정해 두는 것들입니다.

1. 보이스 앤 톤 — 보이스는 제품이 늘 지키는 태도이고, 톤은 상황에 따라 달라지는 어조입니다. 성격은 그대로인데 장례식장과 생일 파티에서 말투가 달라지는 것과 같습니다. 결제가 실패한 화면에서 농담을 하지 않기로 하는 판단이 톤 쪽 결정입니다.
2. 용어 일관성 — 같은 개념에는 늘 같은 단어를 쓴다는 규칙입니다. 앞에서 본 워크스페이스와 팀과 조직 중 하나를 골라 용어집에 적어 두고, 새 화면을 만들 때 그 목록을 먼저 봅니다. 규칙 자체는 단순하지만 지키려면 적어 둔 목록이 있어야 합니다.

확장은 둘이고 순서가 정해져 있습니다.

1. 국제화 — 여러 언어를 담을 수 있게 구조를 미리 잡아 두는 일입니다. 문구를 코드 안에 직접 박아 두면 나중에 번역할 수 없고, 독일어는 같은 뜻을 영어보다 길게 쓰는 일이 많아 글자 수를 고정해 둔 버튼은 깨집니다. 날짜와 통화 형식도 코드가 아니라 설정에서 결정되도록 둡니다.
2. 현지화 — 그 구조 위에서 언어와 문화에 맞게 표현을 바꾸는 일입니다. 번역만이 아니라 예시에 등장하는 이름과 회사, 존댓말의 정도, 주소 입력 칸의 순서까지 바뀝니다.

순서가 뒤집히면 값이 큽니다. 국제화를 건너뛴 채 만든 제품을 나중에 두 번째 언어로 내보내려면 화면을 하나씩 열어 문구를 끄집어내야 하고, 그 작업은 대개 처음부터 구조를 잡는 것보다 오래 걸립니다. 한 언어만 쓰는 동안에도 국제화는 값을 합니다. 문구를 코드 밖으로 빼 두면 문구를 쓰는 사람이 개발자를 거치지 않고 직접 고칠 수 있어서, 단어 하나를 바꾸는 데 배포 일정을 기다리지 않아도 됩니다.

문구를 정하는 판단 기준은 셋으로 줄여 둘 수 있습니다. 사용자가 지금 무엇을 하려는 중인지, 이 말을 읽고 다음에 무엇을 할 수 있는지, 제품의 다른 화면에서 같은 것을 같은 말로 부르고 있는지입니다. 세 번째가 걸리면 혼자 고칠 수 없어서 용어집과 디자인 시스템 쪽 일이 됩니다.

기준이 있어도 문구는 화면마다 새로 써야 합니다. 그래서 쓰는 순서를 정해 두는 팀이 많습니다. 화면을 그리기 전에 그 화면에서 일이 어긋나는 경우를 먼저 적고, 각 경우에 무엇을 알릴지 한 줄씩 채운 다음, 그 줄이 들어갈 자리를 잡아 화면을 그립니다. 반대로 하면 이미 정해진 폭 안에 말을 욱여넣게 되고, 그 과정에서 조건과 다음 행동이 먼저 잘려 나갑니다. 시안에 진짜 문장을 넣어 두는 것도 같은 이유입니다. 자리만 채운 임시 문장으로 두면 그 화면이 읽히는지 아무도 확인하지 않은 채 넘어갑니다.

문구가 가장 많이 걸리는 자리는 사용자가 무언가를 처음 하거나 되돌릴 수 없는 일을 하려는 순간입니다. 가입 직후의 빈 화면, 결제 정보를 넣는 화면, 무언가를 지우기 전 묻는 창, 권한을 넘기는 화면이 그렇습니다. 이 네 자리의 문구만 손봐도 고객센터로 들어오는 문의의 종류가 눈에 띄게 줄어드는 일이 흔합니다.

"이 버튼 '확인' 말고 '삭제'로 바꾸죠. 무엇이 확인되는 건지 안 보여요."

버튼 문구만 읽고 누르는 사용자를 기준으로 삼자는 제안입니다.

"오류 문구에 무엇을 하면 되는지가 없어요. 이러면 그대로 문의로 옵니다."

원인만 알리고 다음 행동을 알려 주지 않는 문구는 사람 손을 부른다는 뜻입니다.

"여기서 워크스페이스라고 쓰면 설정 화면도 같이 고쳐야 합니다."

한 화면의 단어를 바꾸는 결정이 제품 전체의 용어 문제가 된다는 말입니다.

페이지덱에서 이 말들이 한꺼번에 나온 것은 파일 업로드 문의가 몰리던 달이었습니다. 수아가 한 주치 문의 90건을 유형별로 세어 보니 40건이 같은 자리였습니다. 파일을 올렸는데 아무 일도 일어나지 않는다는 문의였고, 실제로는 용량 한도를 넘어 조용히 실패한 것이었습니다. 화면에는 오류가 발생했다는 문장만 떠 있었습니다.

민서가 그 문구를 고치려다 태오에게 막혔습니다. 서버가 실패 원인을 한 종류로만 내려보내고 있어서 화면이 용량 문제인지 형식 문제인지 구분할 수 없었습니다. 문구를 제대로 쓰려면 먼저 원인을 나눠 내려보내야 했고, 그래서 문구 한 줄을 고치는 일이 서버 작업 사흘을 끌고 왔습니다. 고친 뒤 문구는 파일 크기가 20MB를 넘어 올릴 수 없으니 압축하거나 나눠서 올려 달라는 두 문장이 됐습니다.

다음 달 같은 유형의 문의는 40건에서 6건으로 줄었습니다. 지현이 그 자리에서 정한 것은 문구 하나가 아니라 순서였습니다. 그 뒤로 새 화면을 그릴 때 실패하는 경우를 먼저 적고 각각의 문구를 정한 다음 화면을 그리기로 했습니다. 순서를 바꾸자 따라 바뀐 것이 하나 더 있었습니다. 실패하는 경우를 미리 적어 두면 서버가 무엇을 구분해 내려보내야 하는지가 화면을 그리기 전에 정해져서, 태오가 뒤늦게 사흘을 쓰는 일이 없어졌습니다.

UX 라이팅을 짧게 쓰는 일로 아는 경우가 가장 많습니다. 마이크로라는 말이 앞에 붙어 다니고 화면에 자리도 좁으니 자연스러운 오해입니다. 그러나 기준은 길이가 아니라 읽고 나서 다음에 할 일이 보이는가입니다. 파일 크기가 20MB를 넘어 올릴 수 없다는 문장은 오류가 발생했다는 문장보다 두 배 길지만 그만큼 문의를 줄입니다. 짧게 줄이는 것을 목표로 삼으면 줄이는 과정에서 조건과 다음 행동이 먼저 빠져나갑니다. 그 결과로 화면은 깔끔해지고 고객센터는 바빠집니다. 먼저 덜어 낼 것은 조건이 아니라 인사말과 사과입니다. 불편을 드려 죄송하다는 한 줄을 빼고 그 자리에 무엇을 하면 되는지를 넣으면 길이는 그대로인데 문의는 줄어듭니다.

문구는 나중에 채워도 되는 것으로 보는 오해도 흔합니다. 코드나 그림과 달리 언제든 바꿀 수 있는 것처럼 보이기 때문입니다. 실제로는 문구가 화면 구조와 서버 쪽 일을 함께 끌고 다닙니다. 버튼 문구가 두 글자에서 여섯 글자로 늘면 배치를 다시 잡아야 하고, 오류 문구를 제대로 쓰려면 서버가 실패 원인을 구분해 내려보내야 합니다. 이 오해를 그대로 두면 문구는 출시 전날 빈칸을 메우듯 채워지고, 그렇게 채운 문구는 화면에 맞춰 잘려 나가거나 원인을 말하지 못한 채 나갑니다. 번역까지 걸려 있으면 그 밀린 하루가 몇 주로 불어납니다.