마이크로카피

화면 안의 짧은 말은 오랫동안 아무의 일도 아니었습니다. 디자이너는 시안에 글자가 들어갈 회색 막대만 그려 두고, 개발자는 화면을 붙이면서 빈칸을 "확인" 과 "취소" 로 채웠습니다. 기획서에도 어떤 화면이 필요한지는 적혀 있는데 그 화면에 무슨 말이 적히는지는 없었습니다.

그 결과가 드러나는 자리는 늘 정해져 있었습니다. 문서를 지우려고 누르면 "정말 진행하시겠습니까?" 라고만 묻는 창이 떴습니다. 무엇이 사라지는지, 되돌릴 수 있는지, 함께 작업하던 사람들의 화면에서도 없어지는지는 어디에도 없었습니다. 사용자는 창을 닫고 고객센터에 물어보거나, 그냥 눌러 보고 나서 후회했습니다.

문구가 빠진 자리를 사람이 고객센터로 메우고 있다는 사실이 드러나면서 이름이 붙었습니다. 문의를 모아 보면 절반쯤은 제품을 못 쓰겠다는 말이 아니라 지금 화면이 무슨 상태인지 모르겠다는 말이었고, 그런 문의는 화면의 한 줄을 고치면 사라졌습니다. 마이크로카피는 그 한 줄들을 따로 떼어 이름을 주고, 화면을 그리기 전에 정해 두자고 한 것입니다.

문구를 화면에 채워 넣는 장식이 아니라 인터페이스의 한 부품으로 다룹니다. 자리마다 무엇을 알려야 하는지 먼저 정하고, 그 자리에 맞는 말을 넣고, 그 말이 들어갈 만큼 자리를 잡습니다.

한 조각이 답해야 하는 질문은 셋입니다.

1. 지금 어떤 상태인가 — 저장됐는지, 처리 중인지, 실패했는지.
2. 다음에 무엇을 할 수 있는가 — 다시 시도인지, 다른 경로인지, 아무것도 안 해도 되는지.
3. 그걸 하면 무슨 일이 벌어지는가 — 되돌릴 수 있는지, 다른 사람에게도 보이는지.

쓰는 순서를 정해 두는 팀이 많습니다. 화면을 그리기 전에 그 화면에서 일이 어긋나는 경우를 먼저 적고, 경우마다 무엇을 알릴지 한 줄씩 채운 다음, 그 줄이 들어갈 자리를 잡아 화면을 그립니다. 반대로 하면 이미 정해진 폭 안에 말을 욱여넣게 되고, 그때 가장 먼저 잘려 나가는 것이 조건과 다음 행동입니다. "결제에 실패했습니다" 는 여덟 글자에 들어가지만 "카드 한도를 넘었습니다. 다른 카드로 다시 시도해 보세요" 는 들어가지 않습니다.

시안에 진짜 문장을 넣어 두는 것도 같은 이유입니다. 자리만 채운 임시 문장으로 두면 그 화면이 실제로 읽히는지 아무도 확인하지 않은 채 다음 단계로 넘어갑니다. 임시 문장은 늘 짧아서 잘 맞아 보이고, 진짜 문장은 늘 그보다 깁니다.

한 줄을 고르는 기준은 셋으로 줄일 수 있습니다. 사용자가 지금 무엇을 하려는 중인지, 이 말을 읽고 다음에 무엇을 할 수 있는지, 제품의 다른 화면에서 같은 것을 같은 말로 부르고 있는지입니다. 세 번째는 혼자 고칠 수 없어서 용어 일관성 쪽 일이 됩니다. 한 화면에서 워크스페이스라고 부른 것을 다른 화면에서 팀이라고 부르면, 문장 하나하나는 멀쩡해도 사용자는 둘이 다른 것이라고 읽습니다.

제품 안에서 자주 문제가 되는 자리에는 따로 이름이 붙어 있습니다. 넷이 대표적입니다.

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

확인창에 들어가는 문구도 같은 갈래로 다룹니다. 확인창은 되돌릴 수 없는 동작을 묻는 자리라 무엇이 사라지는지를 문장 안에 적습니다. 문서 세 개가 영구 삭제된다고 적은 창과 정말 삭제하겠느냐고만 적은 창은 누르는 손의 확신이 다릅니다.

"이 버튼 '확인' 말고 '삭제'로 바꿔 주세요. 뭘 누르는 건지 모르겠어요."

버튼에 동작 결과를 적어 달라는 요청입니다.

"이 오류 문구는 뭐가 잘못됐는지만 있고 뭘 하면 되는지가 없어요."

다음 행동이 빠졌으니 그 줄을 채우자는 지적입니다.

"시안에 마이크로카피 실제 문장으로 넣어 주세요. 길이가 달라져요."

임시 문장으로 그린 화면은 진짜 문장을 넣는 순간 깨진다는 말입니다.

페이지덱에서는 문서 삭제 확인창이 계기가 됐습니다. 수아에게 "지웠는데 팀원 화면에서도 사라졌다" 는 문의가 한 달에 열 건 넘게 들어왔고, 창에 적힌 말이 "정말 삭제하시겠습니까?" 한 줄뿐이라는 사실이 그때 드러났습니다. 민서가 문장을 "문서 3개가 워크스페이스 전체에서 삭제됩니다. 30일 안에는 휴지통에서 되돌릴 수 있습니다" 로 바꾸고 버튼을 "삭제" 로 고쳤습니다. 다음 달 같은 문의는 두 건으로 줄었습니다.

마이크로카피를 글솜씨 문제로 보는 경우가 많습니다. 짧은 글이고 결과물이 문장이니 잘 쓰는 사람에게 맡기면 될 것처럼 보입니다. 하지만 이 자리에서 막히는 이유는 대개 표현이 아니라 정보입니다. 삭제 확인창의 문장을 쓰려면 문서가 어디까지 사라지는지, 되돌릴 수 있는 기간이 며칠인지를 알아야 하고, 그건 기획과 개발 쪽에 물어야 나옵니다. 문장만 다듬으면 고운 말로 똑같이 모호한 창이 됩니다.

짧을수록 좋다고 보는 것도 흔합니다. 화면이 깔끔해 보이고 번역 비용도 줄어드니 그렇게 믿기 쉽습니다. 그러나 줄여서 뜻이 흐려지면 사용자는 그 자리에서 멈추고 결국 더 긴 경로를 거칩니다. "확인" 두 글자짜리 버튼 앞에서 망설이다 고객센터에 묻는 것보다, "문서 3개 삭제" 라고 적힌 버튼을 바로 누르는 편이 빠릅니다. 기준은 길이가 아니라 이 줄을 읽고 다음 동작을 확신할 수 있는지입니다.