글을 쓰는 데 필요한 시간을 어떻게 예상하십니까?
UX라이팅
이 기사는 스콧 쿠비의 허가 아래 게재하고 있습니다.
(2020년 02월 04일의 기사입니다)
※기사에서는 UX라이팅을 ‘글을 쓴다'라고 일부 표현하고 있습니다
많은 베테랑 웹 전문가들은 콘텐츠 구상으로 인해 프로젝트의 궤도를 벗어나기도 합니다. 콘텐츠를 만드는데 얼마나 많은 작업이 필요할지를 지나치게 과소평가했기 때문에 야심 차게 준비한 출시일이 계속 뒤로 밀려나는 경우가 발생합니다. (그리고 처음부터 콘텐츠로 시작하지 않았기 때문에 예상보다 2-3배 더 오래 걸립니다!)
"이 글을 쓰는 데 얼마나 걸릴까요?" 이것은 함정으로 가득 차 있습니다. 글을 쓴다는 것은 종종 팀과 조직이 이전에 제시할 수 있었던 어려운 결정을 내리도록 강요하는 것을 의미합니다. 환불 정책은 무엇입니까? 플래티넘 플랜으로 정확히 몇 크레디트를 제공합니까? 등등 말입니다.
하지만 당신의 프로젝트 관리자는 햇병아리가 아닙니다. 그들은 프로세스를 시작할 때 콘텐츠를 만드는데 얼마나 오래 걸릴지 묻는 것을 알고 있습니다. 매우 똑똑하죠! 그래서 그들은 당신에게 돌아서서 "이 글을 쓰는 데 얼마나 걸립니까?"라고 묻습니다. 후훗. 매우 조심스럽게 진행할 때입니다.
질문의 목적을 명확히 하세요
당신의 첫 번째 임무는 당신이 묻고자 하는 내용을 완전히 이해하는 것입니다. 그들은 계약의 일부로 예산을 짜기 위해서 입니까? 다른 요청에 비교해 요구하는 시간의 예산을 측정하려면 어떻게 해야 합니까? 글을 쓰는 작업을 다른 일정과 어떻게 맞는지 확인하려면 어떻게 해야 합니까? 글 작성을 완료하는 데 걸리는 시간을 추정하는 것은 하나의 과정이며 그 과정은 글을 작성하는 멤버에게 추측을 바라는 것보다 더 정확하게 접근해야 합니다(추측해서는 안됩니다).
질문의 범위를 명확히 하세요
당신의 팀이 글을 쓰는 과제의 범위를 정하도록 돕는 것은 라이터로써 당신이 하는 일의 일부입니다.
무엇을 작성해야 한다고 요청을 받았나요? 서비스 내의 모든 글인가? 아니면 일부 페이지인가요? 또는 와이어프레임에 표현된 글인가요? 아니면 필요한 모든 상태와 화면 및 메시지의 표면적인 부분만인가요?
당신이 직면하게 될 부분은 글을 쓰는 것보다 글을 쓰는 것에는 더 많은 것들이 있다는 것을 비라이터들이 종종 이해하지 못한다는 것입니다. 글을 쓰는 데 있어서 디스커버리 인터뷰가 필요합니까? 사용자 조사? 이해관계자 프레젠테이션? 디자이너와의 반복적인 작업 세션? 콘텐츠 테스트? QA, 법률 및 규정 준수 검토는 어떠한가요?
신문 기자는 자신의 주제, 마감일, 이상적인 단어 수를 아는 것으로 벗어날 수 있지만 UX라이터와 콘텐츠 디자이너는 자신의 작업을 추정하기 위해 더 많은 것을 알아야 합니다. 가정에 의존하는 추정을 해야 한다는 압박을 받고 있다면 그러한 가정을 문서화하고 우려 사항과 질문을 표명해야 합니다.
워크플로를 계획합니다
함정과 시간 낭비를 줄이는 한 가지 방법은 글쓰기 작업 흐름을 계획하는 것입니다. 과제를 어떻게 준비하고, 작성 (초안)하고, 편집하고 다듬고, 마지막으로 마무리할지에 대한 개요를 작성하면 작성을 완료하는 데 걸리는 시간과 소요되는 시간에 대한 통찰력을 얻을 수 있습니다.
접근 방식을 선택하세요
잘 계획된 워크플로와 범위를 통해 드디어 원래 질문에 답할 준비가 되었습니다. 글을 쓰는데 얼마의 시간이 걸릴까요? 이 시점에서 선택할 수 있는 두 가지 기본 접근 방식이 있습니다.
실제 작업을 기반으로 시간 단위로 추정치를 만듭니다.
마감일과 노력의 관점에서 질문을 재구성합니다.
각각에 대해 살펴보겠습니다.
접근 방식 1 : 실제 작업을 기반으로 시간 단위로 추정치를 만듭니다.
예를 들어 제품 설명이나 사용 방법 기사와 같이 한 가지 종류의 항목을 많이 작성해야 하는 경우 가장 좋은 방법은 해당 항목의 작은 세트를 끝내고 시간을 추적한 다음 나머지를 곱하는 것입니다.
작성해야 하는 50개의 기사 중 5개와 같이 작은 덩어리를 분리하고 별도의 프로젝트로 계획하십시오. 처음부터 끝까지(또는 최대한 가깝게) 작업을 수행하고 도중에 발생하는 장애물과 마찰을 기록합니다.
때때로 팀에서는 진행이 깔끔하지 않기 때문에 별로 좋아하지 않습니다. "왜 우리는 한 번에 모든 것을 할 수 없나요?" 글쎄요, 할 수 있겠지만 우리의 추정치는 부정확할 것이며 때로는 규모에 따라 전체 프로젝트를 방해할 수 있습니다. 때때로 우리는 빠르게 나아가기 위해 일부러 천천히 진행할 필요가 있습니다.
접근 방식 2 : 마감일과 노력의 관점에서 질문을 재구성합니다.
마감일은 예상보다 더 도움이 됩니다. 특히 글이 새로운 주제, 공간 또는 상호 작용을 탐구하는 경우에는 더욱 그렇습니다. 디자인 프로세스의 복잡성으로 인해 단 300 단어로 된 대화형 앱 흐름은 3,000 단어로 된 기사를 작성하는 데 5배 더 오래 걸릴 수 있습니다. 일부 과제는 사람들이 글쓰기를 생각할 때 생각하는 작업에서 1시간만 요구할 수 있지만, 발견, 준비, 조직, 이해 관계자 논쟁 등의 수십 시간이 필요할 수 있습니다.
또한 이해 관계자, 주제 전문가, 편집자, 검토자 및 글을 만질 필요가 있는 모든 사람의 가용성은 주어진 시간 내에 가능한 일에 큰 영향을 미칠 수 있으며 순수한 시간 기반으로 설명하기 어렵습니다.
이러한 이유로 저는 마감일을 선호하는 경향이 있습니다(관리할 수 있다면 시간당 프로젝트 비율). 글을 쓰는 데 “얼마나 걸릴까요?”라는 질문을 받으면 대신 마감 시간을 기준으로 대화를 재구성해 보십시오. 그러면 다음 사항에 대해 알고 싶어 질 것입니다.
콘텐츠는 어떻게 완료되어야 합니까? (거친 초안 또는 완벽한 단어?)
작성 마감일이 나머지 프로젝트와 어떤 관련이 있습니까? (다른 프로젝트 이정표와 구별되는 작성 마감일이 있을 수 있다는 것이 사람들에게 항상 발생하는 것은 아닙니다.)
참여해야 하는 사람은 누구이며 이용 가능 여부는 어떻게 됩니까?
이와 같은 질문이 동료들에게 답답함을 준다면 저도 공감합니다. 때로는 승리를 쟁취하고 함박웃음과 함께 "10시간!"이라고 말하며 전력을 다할 수 있어야 합니다. 그러나 이러한 종류의 질문은 프로세스에 있어서 환영받아야 하며, 자주 묻는 것은 불필요한 리스크가 발생하기 전에 우리가 이해하고 싶은 것이라는 기대를 낳게 될 것입니다.
