UX 라이터

제품 안의 문구는 오랫동안 누구의 일도 아니었습니다. 화면을 만들다가 필요해지면 그 자리에서 적었고, 개발자가 임시로 넣어 둔 말이 그대로 출시됐습니다.

그 결과가 문의 건수로 돌아왔습니다. 파일 업로드가 실패했을 때 오류가 발생했습니다라는 문장을 본 사용자는 무엇을 해야 할지 몰라 고객센터에 씁니다. 같은 상황에서 파일이 20MB를 넘어 올릴 수 없습니다라는 문장을 본 사용자는 파일을 줄여 다시 올립니다. 기능은 같고 코드도 같은데 한쪽은 문의가 되고 한쪽은 해결이 됩니다.

이름이 흔들리는 문제도 쌓였습니다. 같은 자리를 어느 화면에서는 워크스페이스라 부르고 다른 화면에서는 팀 공간이라 부르고 설정에서는 조직이라 부릅니다. 만든 사람들은 세 말이 같은 것을 가리킨다는 사실을 알지만, 처음 쓰는 사람은 세 개의 다른 개념을 배우려 애씁니다. 문구를 자기 일로 삼는 자리가 생긴 이유가 여기 있습니다.

하루는 화면에 붙은 말을 찾아내고 고쳐 쓰고 그 결과가 통하는지 확인하는 일로 채워집니다. 일의 묶음은 다섯입니다.

1. 문구 목록 만들기 — 한 화면에 들어가는 말을 전부 끄집어냅니다. 버튼, 항목 이름, 안내 문장, 오류 안내, 보여 줄 내용이 없을 때의 화면, 확인을 묻는 대화상자, 그 화면에서 나가는 메일의 제목까지입니다. 이렇게 버튼과 안내문 같은 짧은 문구를 따로 다루는 일을 마이크로카피라고 부릅니다.
2. 문구 쓰기 — 짧게 만드는 것이 목적이 아니라 다음 행동이 정해지는 것이 목적입니다. 문제와 해결 방법을 알려 주는 오류 메시지에는 세 가지가 들어갑니다. 무엇이 일어났는지, 어떤 조건 때문인지, 사용자가 무엇을 하면 되는지입니다. 셋 중 마지막이 빠진 문장이 가장 많고, 그 문장이 문의를 만듭니다.
3. 용어 사전 관리 — 같은 것을 한 이름으로 부르게 고정합니다. 워크스페이스와 팀 공간과 조직 가운데 하나를 골라 사전에 적고 모든 화면을 그 말로 맞춥니다. 제품이 말하는 태도와 상황별 어조를 정해 둔 보이스 앤 톤도 같은 문서에 함께 둡니다. 결제 실패를 알릴 때와 문서를 처음 만들 때 쓰는 어조가 같으면 어느 한쪽이 어긋납니다.
4. 시험 — 고친 문구가 나은지 확인합니다. 두 안을 무작위로 나눠 보여 주고 결과를 비교하는 A/B 테스트로 문구만 바꿔 견주는 방법이 가장 확실하고, 트래픽이 적으면 사용자에게 5초만 보여 주고 무슨 뜻으로 읽었는지 물어보는 방법을 씁니다.
5. 다른 말로 옮길 자리 마련 — 한국어로 열두 자인 버튼이 독일어로 옮기면 스물여덟 자가 됩니다. 언어와 문화에 맞게 표현을 바꾸는 현지화를 나중에 하더라도, 지금 자리 폭을 넉넉히 잡아 두지 않으면 그때 화면을 다시 그려야 합니다.

문구는 화면과 같은 시점에 정해져야 하고 코드에 들어가는 순간 손이 닿지 않게 됩니다. 그래서 다섯 자리와 맞물려 움직입니다.

1. 디자이너 — 가장 붙어 있는 자리입니다. 민서가 시안을 그릴 때 문구가 함께 들어가야 자리 폭과 줄 수가 맞습니다. 회색 상자만 그려 놓고 문구를 나중에 끼우면 서른 자짜리 문장이 두 줄 자리에 안 들어가는 일이 생깁니다.
2. 개발자 — 문구가 코드 안에 흩어져 있으면 한 글자를 고칠 때마다 개발 일정을 기다려야 합니다. 태오가 문구를 별도 파일로 빼 두면 라이터가 직접 고쳐 올릴 수 있고,
3. 프로덕트 매니저 — 무엇을 알려야 하는지 정하는 쪽입니다. 지현이 새 기능의 동작을 설명해 주면 그중 사용자가 알아야 하는 부분만 골라 문장으로 옮깁니다.
4. 고객 성공과 고객 응대 — 어느 문구가 문의를 만드는지 알려 주는 쪽입니다. 수아에게 같은 질문이 한 달에 서른 번 들어온다면 그 화면의 문구가 답을 못 하고 있다는 뜻입니다.
5. 법무 — 결제와 개인정보 안내에는 표현을 바꿀 수 없는 문장이 섞여 있습니다. 규원이 검토를 거치는 문구는 읽기 좋게 다듬는 범위가 미리 정해집니다.

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

오류 안내에서 해결 방법이 빠졌다는 지적입니다.

"워크스페이스로 통일하기로 했으니 설정 화면의 조직도 바꿔 주세요."

용어 사전에 적힌 이름과 화면이 어긋난 자리를 찾아낸 요청입니다.

"버튼 자리를 조금 넓혀 주세요. 다른 언어로 옮기면 두 줄이 됩니다."

지금 화면이 아니라 나중의 번역을 미리 계산한 요청입니다.

페이지덱에는 전담 라이터가 없어서 민서와 지현이 나눠 맡고 있습니다. 둘이 만든 용어 사전에는 서른 개쯤의 말이 올라가 있고, 새 화면을 만들 때 그 사전을 먼저 봅니다. 지난 분기에는 업로드 오류 문구 열두 개를 다시 썼는데, 무엇을 하면 되는지를 한 줄씩 붙인 뒤로 그 화면 관련 문의가 절반으로 줄었습니다.

글을 잘 쓰는 사람이면 할 수 있다고 읽는 경우가 가장 많습니다. 결과물이 문장이라서 자연스러운 오해입니다. 하지만 제품 안의 문구는 기능이 어떤 조건에서 어떻게 동작하는지를 알아야 쓸 수 있습니다. 업로드가 실패하는 이유가 용량 때문인지 형식 때문인지 권한 때문인지 모르면 오류가 발생했습니다 말고는 쓸 문장이 없습니다. 방향도 다릅니다. 홍보 문구는 눈에 띄어야 하고 제품 안의 문구는 읽는 줄도 모르게 지나가야 합니다. 화면 안에서 재치를 부린 문장은 두 번째로 볼 때부터 거슬립니다.

문구는 마지막에 끼우면 된다고 읽는 것도 흔합니다. 화면이 정해지면 그 안에 들어갈 말은 따라 나온다고 보기 쉽습니다. 그런데 문장을 써 보다가 화면 구조가 틀렸다는 사실이 드러나는 일이 자주 있습니다. 이 버튼이 무엇을 하는지 한 단어로 적을 수 없다면 그 버튼이 두 가지 일을 하고 있다는 뜻입니다. 이때 문구를 비틀어 두 동작을 한 문장에 담으면 구조 문제가 문장으로 덮이고, 사용자는 눌러 본 뒤에야 무슨 일이 일어나는지 압니다. 제품 안의 문구를 설계하는 일 전체를 가리키는 UX 라이팅이 화면 설계와 같은 시점에 들어가야 하는 이유입니다.