Community

굿바이 라이팅 요청 채널

✍ 기획자의 글쓰기 시리즈 [📝 굿바이 라이팅 요청 채널] (👀 간단 요약) ✓ 최근 우리 팀 UX 라이팅 업무 프로세스엔 큰 변화 ✓ 슬랙의 ‘UX 라이팅 업무 요청 채널'이 없어진 것 📌 라이팅 요청 채널의 탄생 ✓ 라이팅 업무 요청 채널(채널명 #uxw-request)은 거의 처음으로 만든 채널 ✓ 다른 팀원들이 UX 라이터들에게 업무 요청을 할 수 있는 기본적인 소통 공간 ✓ 최초 가이드엔 아래 항목이 포함 ✓ 프로젝트 이름, 이슈 요청자, 리뷰 요청 범위, 배포 시점, 화면 자료(피그마, 문서 링크 등) ✓ 라이팅 요청 채널은 팀원들에게 ‘UX 라이터와 일하는 방법’을 배울 수 있는 학습 창구 역할 ✓ UX 라이터의 존재도 많은 팀원들이 알게 되고, 업무도 점점 많이 들어오게 됨 📌 라이팅 요청 채널의 한계 : 계속되는 스무고개 ✓ 업무 요청 가이드가 UX 라이터를 완벽하게 도와주진 못함 ✓ 일단 모든 업무 요청이 가이드에 맞춰 들어오지 않음 ✓ 라이터들은 스레드에서 계속 질문해가며 스무고개 하듯 어떤 요청인지 파악해야 ✓ 신규 서비스의 경우 라이팅을 위해 새로운 맥락에 대한 방대한 학습이 필요 ✓ 가이드에 맞춰서 업무 요청이 와도 여전히 일을 시작하기 힘듦 📌 라이팅 요청 채널의 한계 : 우선순위 산정의 어려움 ✓ 회사라면 당연히 로드맵 상 더 중요한 일과 덜 중요한 일이 존재 ✓ UX 라이터도 제품팀의 구성원으로서 제품에 크게 임팩트 낼 수 있는 이슈가 뭔지 파악, 공수 산정 필요 ✓ 라이팅 요청 채널로 들어오는 업무들은 어떤 게 더 우선이고 어떤 건 나중에 해도 되는 건지 파악이 어려움 ✓ 사정을 모르니 라이팅 요청 채널에 들어오는 업무는 대부분 평등하게 취급 ✓ 나중엔 가이드에도 우선순위 항목을 추가 ✓ 기본은 Moderate, 주요 이슈는 Major, 당장 해야 하는 건 Hotfix로 구분 📌 맥락의 분리는 라이팅 외주화를 만든다 ✓ 여전히 요청 채널로 들어오는 업무에서 맥락 파악에 너무 많은 수고가 필요 ✓ 요청 채널이나 가이드 같은 툴에서 문제를 찾을 게 아니라, '왜 맥락을 파악하기 어려운지' 문제의 근본을 찾기 위해 Deep dive ✓ 쉽고 명확하게 전달하기 위해선 일단 UX 라이터 자신이 누구보다 그 내용을 잘 알아야 ✓ 사용자 수준에서 PO, 디자이너, 필요에 따라 개발자 수준까지 제품 이해도를 끌어올려야 ✓ 처음부터 UX 라이터가 PO, 디자이너와 비슷한 프로젝트 이해도를 갖고 있다면 이해도를 끌어올릴 필요가 없음 📌 풍부한 맥락은 라이터를 UX 설계에 참여하게 한다 ✓ 왜 개선되어야 하는지, 가설은 무엇인지, 성과 지표는 무엇인지 등을 아는 게 UX 라이터에게도 중요 ✓ 맥락을 알면 UX 라이터의 작업은 윤문에서 그치는 게 아닌 ✓ 정말 라이팅이 필요한지, 필요 없는 정보는 아닌지, 더 나은 정보 위계는 없을지까지 고민 가능 ✓ 하지만 얕은 맥락만 가지고서는 당연히 더 치열한 고민을 할 수 없음 📌 One Team으로 일하기 ✓ 해당 프로젝트의 슬랙 채널이 따로 있다면 그 채널에서 라이팅 이슈도 커뮤니케이션하기 시작 ✓ 다른 이해관계자들이 커뮤니케이션하는 내용들도 있으니 라이터가 맥락 파악에 도움 ✓ 이슈가 들어오면 요청자에게 라이팅 작업을 위한 맥락 학습이 필요함을 설명하고 이를 위한 미팅을 생성 ✓ 라이팅 요청 채널을 통한 업무 커뮤니케이션은 자연스레 줄어들기 시작 📌 라이팅은 마법의 가루가 아니다 ✓ 가장 좋은 건 '처음부터 같이 일하기' ✓ 디자이너가 문제 정의와 가설 수립, 어떤 UX 해결책이 있을지 고민하기 시작할 때 UX 라이터도 같은 고민을 하는 것 ✓ UX 라이터는 PO가 정책을 수립할 때 워딩 관점에서 의견을 내고 ✓ 디자이너가 UI를 설계할 때 정보 위계 정의를 함께할 수 있음 ✓ 서비스 회원가입 플로우에서 일어날 수 있는 에러 케이스 라이팅 작업이라면? ✓ 맥락을 모르고 처음부터 참여하지 않으면 설계가 완료된 뒤 기계적으로 메시지 작성 ✓ 처음부터 참여했다면 에러 케이스를 줄일 수 있는 방법까지 함께 참여 가능 📌 라이팅도 같이 가요 ✓ 우리팀은 UX 설계가 50% 정도 완료 되었을 때 UX 라이터가 참여하는 것을 지향 ✓ 업무 성격에 따라 70-80% 올라왔을 때 참여하기도 함 ✓ UX 설계 참여도가 높아지고, 맥락 파악의 난이도는 낮아짐

알림

알림이 없습니다