UX Writing Step 1
제품에서의 사용자 중심 글쓰기 기본 원칙들
한 때 '개자이너', 즉 개발하는 디자이너라는 말이 유행이었다. 코드를 읽을 줄 알고, 나아가 개발까지 하는 디자이너의 능력이 시장에서 알아주는 스페셜리티로 주목 받았다. 그리고 이는 현재도 유효하다. 코딩뿐만 아니라 마이크로 인터렉션, 3D, 프로토타이핑 등 프로덕트 디자이너가 키울 수 있는 skill set은 점점 다양해지고 상향 평준화 되고있다.
이제는 글쓰기도 디자이너의 스킬로 각광받는다. 사실 '디자이너의 글쓰기'라는 말은 넓은 의미를 포함하지만 이 글에서 다루고 싶은 글쓰기는 자신의 이야기를 잘 풀어내는 글쓰기는 아니다. 제품의 이야기를 하는 글쓰기, 'UX Writing'이다.
https://uxdesign.cc/how-to-simplify-complex-technical-information-4a34f995819d
나는 글쓰기, 문장을 다루는 것을 좋아한다. 그래서 디자인할 때도 워딩이 필요한 순간이 오면 좀 더 고민하는 편이고 자연스레 ux writing에 관심을 갖게 됐다. 하지만 아쉽게도 ux writing은 ux 관련 다른 주제에 비해 국내 자료가 아직 많이 부족하다. 내가 공부하면서 관련하여 처음 본 자료도 위 두 영문 아티클이었다. 그리고 현재는 위 'Are you sure you want to do this? Mocrocopy for confirmatin dialogues'를 쓴 킨너렛 이프라(Kinneret Yifrah)의 책 <마이크로 카피>를 아주 인상 깊게 읽고 있다. 다행히 국내에 훌륭한 번역본이 나와있다. 아티클도 찾고 책도 읽고 있지만 무엇보다 요즘 실무에서 ux writing을 고민해볼 기회가 많이 생겼다. 그러면서 머릿속에 관념적으로만 갖고 있었던 ux writing 원칙을 정리해봐야겠다고 생각했다.
1. 같은 말을 다르게 쓰고 있지 않은가
가장 기본적인데 은근히 지켜지지 않는 경우가 많다. '포인트와 쿠폰을 관리할 수 있는 앱'을 예로 들어 본다. 쿠폰 관리 페이지에서는 쿠폰에 '사용 종료일'이라는 말이 쓰인다. 그런데 어느 페이지의 모달(modal)에서는 '쿠폰 만료일이 지났습니다.'라는 문장이 튀어나올 수도 있는 것이다. 종료면 '종료', 만료면 '만료'로 같은 말은 같은 워딩을 써야 한다. 비슷한 의미를 담고 있는 말을 다르게 쓰고 있지 않은지 확인한다.
2. Writing tone이 제품의 톤앤매너와 일치하는가
예를 들어 Z세대 타깃의 SNS 플랫폼에 지자체 공문같은 Writing tone을 쓰진 않을 것이다. 우리 제품의 성격과 메시지의 보이스톤이 일치하는지 확인한다. 제품도 한 명의 페르소나라고 가정하고 사용자에게 어떻게 말을 걸지 상상해 본다. 제품이 사용자의 비즈니스 파트너일 때와 여가 생활을 도와주는 친구같은 서비스일 경우는 그 보이스 톤이 분명 다를 것이다.
3. 꼭 있어야 할 말인가
위 페이지를 보면 왼쪽(A) 화면엔 모든 텍스트 필드(text filed)마다 '닉네임을 입력해주세요, 이름을 입력해주세요'같은 플레이스 홀더(place holder)가 있다. 그런데 사실 레이블에 '닉네임', '이름'처럼 사용자가 무엇을 입력해야 하는지 명시하고 있으므로 굳이 똑같은 이야기를 두 번 할 필요는 없다. '지역' 필드처럼 다른 텍스트 필드랑 다른 UI 플로우로 이어질 때만 플레이스 홀더를 남겨줘도 충분하다.
반복되는 워딩이 많을수록 당연히 화면도 복잡해 보인다. 또, 무엇을 '~해주세요.' 같은 문장은 사용자가 부담스럽기 쉬운 워딩이라 꼭 필요할 때만 쓰는 게 좋다고 생각한다.
4. 한 문장에 많은 액션을 담고 있진 않은가
왼쪽(A)와 오른쪽(B) 중 어느 모달(modal)의 문장이 더 좋은 문장일까? 답은 왼쪽(A)이다. 한 문장에 사용자가 수행하는 동작을 한 가지 이상 담지 않는게 좋다. 오른쪽(B)은 한 문장에 '1. 취소'와 '2. 내 리뷰 나가기'라는 두 가지 액션이 한꺼번에 들어가 있다. 프로덕트 디자인 원칙에서 한 페이지에 여러 액션을 담지 않는 것과 비슷한 맥락이다. 문장은 최대한 간결하게 표현되어 단번에 이해가 가능해야 하고, 원인과 결과가 명확히 드러나야 한다.
5. 사용자의 동작을 확인 해주었는가
이것도 기본적인데 놓치기 쉽다. 삭제를 했으면 삭제가 되었다, 실행 취소를 했으면 실행 취소가 되었다, 저장이 안 되었으면 저장이 안 되었다고 사용자에게 알려줘야 한다. 그리고 오류 등으로 사용자의 동작이 원하는 대로 실행이 안됐을 때는 거기서 끝나는 게 아니라 그러면 어떻게 해야 하는지 (재시도를 해봐야 하는지, 고객센터에 문의해야 하는지)까지 알려줘야 한다.
그밖에 너무나도 당연한 맞춤법 지키기, 문장에 성/장애/지역/외모/인종 등의 차별이 담겨 있진 않은지 체크하기도 있겠다.
요새는 자신의 실무 경험이나 작업물을 글로 잘 표현하는 디자이너는 쉽게 찾을 수 있다(디자이너들은 못하는 게 무엇인가?). 디자이너의 논리 정연한 문장력은 커뮤니케이션 능력으로 치환된다. 하지만 제품(서비스)의 이야기를 화면에 똑똑하게 녹여내는 일은 디자이너가 위와 별개로 익혀야 하는 분야다.
프로덕트, 서비스 디자인 분야에서 경험을 쌓아가며 느끼는 점 중 하나는 글을 쓸 일이 무지 많다는 것이다. 생각해보면 서비스 전체에서 글이 없는 화면은 드물다. 거의 모든 화면은 "무엇을 해라, 해볼래?, 하지 말아라, 진짜 할 거니!"와 같이 계속해서 사용자에게 말을 걸고 있다. 알아갈수록 UX Writing이 프로덕트 디자이너에게 개발 지식만큼 실무에서 활용하기 좋은 스킬이라는 생각이 든다. 앞으로 더 공부해 UX Writing, 마이크로 카피가 제품 안에서 어떤 시너지를 낼 수 있는지 실험해 보고 싶다.
