굿바이 라이팅 요청 채널
UX 라이터가 업무 요청 채널을 없앤 이유
최근 우리 팀 UX 라이팅 업무 프로세스엔 큰 변화가 일어났다. 바로 슬랙의 ‘UX 라이팅 업무 요청 채널'이 없어진 것이다.
입사와 동시에 UX 라이팅 팀의 인프라를 구축하기 위해서 여러 시도를 해왔다(우리 회사엔 UX 라이터가 나 포함 두 명으로, 같은 날 입사한 최초 UX 라이터들이다!). UX 라이터의 R/R 정의부터 시작해서 디자이너와 피그마 협업 세팅 등... 많은 프로세스가 생겼다가, 고쳐졌다가, 없어지기도 했다. 그리고 이제는 라이팅 업무 요청 채널을 역사 속으로 보내게 되었다.
라이팅 요청 채널의 탄생
라이팅 업무 요청 채널(채널명 #uxw-request)은 거의 처음으로 만든 채널이었다. 다른 팀원들이 UX 라이터들에게 업무 요청을 할 수 있는 기본적인 소통 공간이었다.
채널을 만들고 간단한 업무 요청 가이드를 세워, 업무 시작에 필요한 최소한의 정보를 파악하고자 했다. 최초 가이드엔 아래 항목이 포함되었다.
프로젝트 이름
이슈 요청자
리뷰 요청 범위
배포 시점
화면 자료(피그마, 문서 링크 등)
최초 라이팅 업무 요청 가이드UX 라이터는 업무 시 이슈의 맥락을 파악하는 데 정말 많은 시간을 쓴다. “00 화면에 들어가는 문구 부탁해요.” 보다는 간단하게라도 요청 형식이 생기니 작업에 필요한 정보를 빨리 파악할 수 있었다.
라이팅 요청 채널은 팀원들에게 ‘UX 라이터와 일하는 방법’을 배울 수 있는 학습 창구 역할도 했다.
요청 채널엔 거의 대다수의 제품팀 인원이 들어와 있었다. 그리고 그땐 아직 회사에 UX 라이터가 생긴 지 고작 두세 달 돼가던 터라, 계속해서 팀에 UX 라이터의 역할을 이해시키던 시기였다. 요청 채널에선 우리가 작업 요청자들과 커뮤니케이션하는 내용들을 모든 사람이 볼 수 있기 때문에 UX 라이터와 협업하는 방식을 보고 학습할 수도 있었다.
또, 라이터들의 업무가 가시화되니까 UX 라이터의 존재도 많은 팀원들이 알게 되고, 업무도 점점 많이 들어오게 되었다. 아직은 팀에 UX 라이터의 역할을 설파하던 단계였기 때문에 우리를 찾는 사람이 많아지는 건 좋은 신호였다.
라이팅 요청 채널의 한계
계속되는 스무고개
하지만 업무 요청 가이드가 UX 라이터를 완벽하게 도와주진 못했다. 일단 모든 업무 요청이 가이드에 맞춰 들어오지 않았다. 사람에 따라 여전히 “00 화면에 들어가는 문구 부탁해요.” 식으로 띡 요청이 들어올 때도 있었다. 당연히 그 정도 맥락으론 라이팅을 하기 어렵고, 라이터들은 스레드에서 계속 질문해가며 스무고개 하듯 어떤 요청인지 파악해야 했다.
작업 범위 또한 애매했다. 업무 요청자가 처음에 범위를 지정해줘도, 실제로 작업 맥락을 파악하고 나면 예상했던 것과 리소스가 다를 때가 많았다. 예를 들면 ‘00 모달의 문구 1줄 작업 요청드립니다.’라고 요청이 들어와도, ‘1줄'이라는 범위가 UX 라이터의 실제 작업 리소스와 일치하기 어렵다. 단어 하나, 문장 한 줄을 다듬는 일도 알고 보면 엄청나게 복잡한 정책들이 주렁주렁 고구마 줄기처럼 엉켜 있을 때가 많았다.
또, 신규 서비스의 경우 라이팅을 위해 새로운 맥락에 대한 방대한 학습이 필요하기 때문에, 이런 건 가이드에 맞춰서 업무 요청이 와도 여전히 일을 시작하기 힘들었다. 결국은 마찬가지로 긴 스레드가 생기게 될 때가 많았다.
우선순위 산정의 어려움
당시 UX 라이터들의 업무는 '1. 라이팅 시스템 2. 각자 맡은 서비스 도메인의 라이팅 (예를 들어 나는 해외여행 서비스의 라이팅을 담당하고 있다.) 3. 산발적으로 들어오는 라이팅 요청 채널 업무'까지 크게 세 종류였다. 그런데 특히 3번, ‘라이팅 요청 채널 업무'는 업무 간 우선순위 산정이 잘 안 되었다.
회사라면 당연히 로드맵 상 더 중요한 일과 덜 중요한 일이 있다. 상대적으로 중요한 목표엔 더 많은 개발 인력, 더 많은 디자이너가 투입되기 마련이다. 이처럼 UX 라이터도 제품팀의 구성원으로서 제품에 크게 임팩트 낼 수 있는 이슈가 뭔지 파악하고, 거기에 더 많은 공수를 산정하는 것이 필요했다.
하지만 라이팅 요청 채널로 들어오는 업무들은 어떤 게 더 우선이고 어떤 건 나중에 해도 되는 건지 파악이 어려웠다. 사정을 모르니 라이팅 요청 채널에 들어오는 업무는 대부분 평등하게 취급되었다. 그러다 보니 알고 보니 그렇게 우선순위가 높지 않은 작업에 라이터가 너무 많은 리소스를 써버리기도 했다.
나중엔 가이드에도 우선순위 항목을 추가했다. 기본은 Moderate, 주요 이슈는 Major, 당장 해야 하는 건 Hotfix로 구분했다. 더불어 '라이팅 개선으로 예상되는 임팩트'도 추가했는데, 이 또한 라이터가 해당 업무가 얼마나 임팩트가 큰 업무인지 가늠하는 데 도움이 됐다.
이런 식으로 어떻게 하면 라이팅 요청 채널 업무를 더 효율적으로 할 수 있을지 계속 개선 방향을 고민했다. 가이드도 이에 따라 계속 업데이트되었다.
나중엔 우선순위를 파악하기 위해 가이드에 'Urgency' 항목을 추가했다.
개인 노션의 업무 고민을 모아놓은 페이지에도 요청 채널이 많은 부분을 차지하고 있었다!문제는 다시 맥락이야!
맥락의 분리는 라이팅 외주화를 만든다
하지만 그럼에도 불구하고 라이터들은 여전히 요청 채널로 들어오는 업무에서 맥락 파악에 너무 많은 수고를 들이고 있었다. 이쯤 되니 문제는 라이팅 요청 채널 자체가 아닌 것 같았다. 요청 채널이나 가이드 같은 툴에서 문제를 찾을 게 아니라, '왜 맥락을 파악하기 어려운지' 문제의 근본을 찾기 위해 Deep dive 했다.
문제는 다시 '맥락'이었다. 쉽고 명확하게 전달하기 위해선 일단 UX 라이터 자신이 누구보다 그 내용을 잘 알아야 한다. 따라서 단시간에 사용자 수준에서 PO, 디자이너, 필요에 따라 개발자 수준까지 제품 이해도를 끌어올려야 한다(이전 글 'UX 라이터로 1분기를 보내며' 중).
그렇다면, 바꿔 말해 처음부터 UX 라이터가 PO, 디자이너와 비슷한 프로젝트 이해도를 갖고 있다면 나중에 '이해도를 끌어올릴' 필요가 없다는 뜻이다.
당시 라이팅 요청 채널의 모습은 일종의 라이팅 에이전시였다. 그때그때 서로 다른 클라이언트의 ‘건 by 건’ 의뢰처럼 요청이 들어오고, 라이터는 마치 외부의 라이팅 조력자처럼 일했다. 하지만 에이전시는 해당 프로젝트가 어떤 맥락에서 생겼고, 비즈니스상 어떤 중요도를 차지하고 있는지 인하우스 팀원만큼 알기 힘들다.
풍부한 맥락은 라이터를 UX 설계에 참여하게 한다
어떤 화면의 UX 개선에 라이팅이 필요하다면, 이 화면이 왜 개선되어야 하는지, 가설은 무엇인지, 성과 지표는 무엇인지 등을 아는 게 UX 라이터에게도 중요하다. 이런 프로젝트의 맥락을 알면 UX 라이터의 작업은 윤문에서 그치는 게 아닌, 나아가 정말 라이팅이 필요한지, 필요 없는 정보는 아닌지, 더 나은 정보 위계는 없을지까지 고민할 수 있게 된다. UX 디자이너처럼 정말로 UX 설계에 관여할 수 있게 되는 것이다. 하지만 얕은 맥락만 가지고서는 당연히 더 치열한 고민을 할 수 없다.
(*윤문: 문장을 다듬는 일)
One Team으로 일하기
이런 공감대가 UX 라이터들 사이 빠르게 맞춰졌다. 정보를 쉽게 가공하는 것에 그치지 않고, 그 정보의 필요 유무와 역할까지 우리가 정의해야 한다고 생각했다. 그리고 이를 위해 라이팅 에이전시가 아닌 'One Team처럼 일하기'가 필요했다.
요청 채널이 아직 있긴 했지만 해당 프로젝트의 슬랙 채널이 따로 있다면 그 채널에서 라이팅 이슈도 커뮤니케이션하기 시작했다. 프로젝트 채널엔 다른 이해관계자들이 커뮤니케이션하는 내용들도 있으니 라이터가 맥락 파악에 도움 됐다. 마침 이때쯤 팀 차원에서도 두 명의 UX 라이터에게 서비스 도메인이 명확하게 나뉘어젔다. 전처럼 누구의 담당도 아닌 이슈가 들어왔을 때 매번 분담을 해야 하는 수고가 사라졌다.
또한, 업무 요청 가이드 개선에 더 이상 집착(?) 하지 않고, 이슈가 들어오면 요청자에게 라이팅 작업을 위한 맥락 학습이 필요함을 설명하고 이를 위한 미팅을 생성했다. 구두로 얘기하니 20분 내외 미팅이어도 짧은 시간에 밀도 있게 작업에 필요한 정보를 제공받을 수 있었다.
이런 방식이 안정화되기 시작하니까 라이팅 요청 채널을 통한 업무 커뮤니케이션은 자연스레 줄어들기 시작했다. UX 라이터와 팀원들은 해당 프로젝트의 채널에서, 미팅에서 프로젝트의 팀원들과 함께 맥락을 나누었다.
라이팅은 마법의 가루가 아니다
하지만 UX 라이터가 PO나 디자이너만큼 프로젝트 이해도를 가지고 있으려면 이 정도론 부족하다. 가장 좋은 건 처음부터 같이 일하는 것이다.
디자이너가 문제 정의와 가설 수립, 어떤 UX 해결책이 있을지 고민하기 시작할 때 UX 라이터도 같은 고민을 할 수 있다. 예를 들어 UX 라이터는 PO가 정책을 수립할 때 워딩 관점에서 의견을 내고, 디자이너가 UI를 설계할 때 정보 위계 정의를 함께할 수 있다.
그런데 이런 생각을 글로벌 회사의 UX 라이터도 하고 있나 보다. 지난 5월 Figma에서 주최한 디자인 콘퍼런스에서 UX 라이팅 세션 <Working with UX writers in Figma>를 몰입하여 들었는데, 'UX 라이터를 최대한 프로젝트에 빨리 투입시켜야 한다.’는 이야기가 인상 깊었다.
아래 슬라이드를 보면, UX 라이터가 디자인, 프로덕트 담당과 같은 시작점에서 일을 시작하기를 권한다. 라이팅 작업이 일찍 고려될수록 ‘정말로’ UX 문제를 해결하는데 기여할 수 있다는 것이다.
(Figma 2022 디자인 콘퍼런스의 'Working with UX writers in Figma' 세션 슬라이드 중)
UX 라이팅이 프로젝트 후반에 시작되면 UX 문제를 해결할 수 없다.
UX 라이팅이 디자인, 제품 기획과 마찬가지로 초반부터 시작되어야 한다.그리고 일해보니 정말 그렇다. 예를 들면 '서비스 회원가입 플로우에서 일어날 수 있는 에러 케이스'의 라이팅 작업을 한다고 치자. 첫 번째 이미지가 UX 설계가 이미 다 fix 된 상태에서 수많은 에러 메시지를 기계적으로 쓰는 모습이라면, 두 번째 이미지처럼 일하면 UX 라이터는 '플로우 초반에 비밀번호 규칙이나 전화번호 인증 과정을 더 명확하게 알려주면 에러 케이스를 줄일 수 있지 않을까?'라는 제안까지 할 수 있다.
라이팅 요청 업무를 하다 보면 가끔씩 여기에 라이팅을 더하거나 빼는 게 UX 개선에 크게 의미가 없는 경우도 있다. 그런 작업은 사실 처음부터 UX가 엉성하게 짜인 경우가 많다. 라이팅 개선으로 UX 개선을 당연히, 또 훌륭하게 할 수 있다. 하지만 그 역할이 어떤 '마법의 가루'가 될 때는 드물다. UX 라이팅은 마지막에 첨가하는 '후첨 스프'가 아닌, 처음부터 구비된 식재료여야 맛있는 요리를 만드는 데 근본적인 도움이 될 수 있다. 후첨 스프로 이미 맛 없는 요리(...)를 구하기는 쉽지 않다.
라이팅도 같이 가요
(적어도 현실 세계가 허락한만큼은)
하지만 현실적으로 UX 라이터가 모든 프로젝트의 초반부터 참여하기 쉽지 않은 것도 사실이다. 우선 대부분 조직에서 UX 라이터는 디자이너나 PO만큼 리소스가 많지 않다. 나만 해도 1~2가지 프로젝트에만 속한 게 아닌 거의 10가지 도메인을 맡고 있다. 그래서 무조건 모든 프로젝트를 처음부터 함께하는 게 오히려 비효율일 수도 있다(몸을 쪼개는 데도 한계가 있다!). 조직 상황에 따라 UX 라이터의 효율적인 투입 시점을 찾아내야 한다.
우리 팀은 여러 테스트 끝에 현재는 UX 설계가 50% 정도 되었을 때 UX 라이터가 참여하는 것을 지향하고 있다. 또, 업무 성격에 따라 설계가 7~80% 정도 올라왔을 때 참여하기도 한다. 실제로 이렇게 일해보니 95%, 99%까지 진행되었을 때 UX 라이터가 투입되는 것보다는 확실히 라이터의 UX 설계 참여도는 높아지고 맥락 파악의 난이도는 낮아졌다.
2022년 7월, UX 라이팅 업무 요청 슬랙 채널은 아카이브 되었다. 채널은 어떻게 하면 UX 라이터로서 조직에, 또 제품에 큰 임팩트를 낼 수 있을지 고민하며 남긴 수많은 발자국 중 하나가 되었다. 두 명뿐이지만 팀이라면 팀인, UX 라이팅 팀의 한 챕터가 마무리 되는 기분이 든다.
그리고 나는 조직의 최초 UX 라이터가 된지 7개월 차가 되었다. 반년 동안 인프라를 갖추는 데 공을 정말 많이 들인 것 같다. 이제 기반은 어느정도 닦아 놨으니 하반기는 퍼포먼스를 내는 일에 집중하려고 한다.
디지털 라이팅의 역사 자체는 오래 됐지만(태초에 웹이 있었노라...), 'UX writer'라는 직업적인 역할은 아직도 시장에서 자리 잡아가는 과정에 있는듯하다. 그리고 UX 라이팅을 '언어로 하는 디자인'이라고 많이들 말하지만, 실제로 일하는 모습을 보면 아직은 '언어적 조력자' 정도로 한정되어 있는 곳이 많아 보인다. 그만큼 UX 라이터들 스스로가 조직 내외로 자신의 역할을 정의하고, 또 설파하는 게 중요하다. 그 과정에서 이런 치열한 고민의 이야기들이 선례가 될 거라고 생각한다. UX 라이터로서 고군분투하고 있는 사람이 있다면 이 글을 건네주며 그의 경험도 찐하게 들어보고 싶다.
