1, 2장은 Introduction 파트입니다.
장 제목에서 알 수 있듯이 테크니컬 인포메이션 분야는 지금도 계속 새로운 방향으로 나아가고 있고, 그 과정에서 이 책을 펴낸 것이다라는 의미를 강조하고 있습니다.
이 책이 출판된 것은 2014년인데, 이제 막 Headless 개념이 등장하면서 한번 더 테크니컬 라이팅 시장이 바뀌기 시작할 때입니다. 이 책의 저자들이 90년대 경력을 시작했다면 DTP, 온라인 문서, CMS 등의 변화를 몸으로 겪은 세대였다는 거죠(3판 저자는 대부분 80년대 후반에서 90년대 초반에 졸업을 했습니다. 졸업 후 바로 경력을 시작했다면 90년대 경력을 시작한 것으로 볼 수 있죠).
In testing, when users were forced to seek additional assistance, a majority in our tests tried to search the Internet or visit a video site such as YouTube rather than reading the help. This finding is surprising at first, but on reflection, is the equivalent of asking a colleague.
요즘에는 AI의 등장으로 검색의 역할이 줄어들긴 했습니다. AI 시대에도 asking a colleague라는 의미는 변하지 않았네요.
One reason that users avoid help documentation is that we, as a profession, have taught them that, as one user told us, “There’s nothing good there.” For example, when we moved from command-oriented products to those with graphical interfaces, technical information was focused on helping users to understand how to manipulate the user interface. Although that focus made sense during the transition, many writers continue that focus today, 20 years after the transition. In spite of knowing better, we continue to produce huge amounts of help documentation.
어떻게 보면 상당히 중요한 메시지입니다. 20년 전(1980년대)에는 GUI 환경이 처음 등장하면서 사용자들이 이를 어떻게 사용해야 하는지 어려움을 겪었습니다. 때문에 문서를 통해 GUI를 다루는 방법을 설명하는 것이 필요했었죠. 하지만 이제는 대부분 사용자들이 GUI 환경에 익숙해졌고 따로 문서를 찾아보지 않아도 기본적인 사용법은 알고 있습니다. 하지만 여전히 제품 매뉴얼에서는 GUI 사용법을 설명하고 있고, 때로는 실제 제품의 동작과 다른 내용을 설명하고 있습니다. 이런 문제가 오래 쌓이면서 사용자들에게 제품 매뉴얼의 품질이 좋지 않다는 생각이 생겼고 제품 매뉴얼을 더 이상 찾아보려 하지 않는다는 겁니다.
We need to write information for users where they are, focused on what they’re trying to accomplish, instead of trying to make them read what they don’t want to read.
사용자가 문서를 읽지 않는 이유는 품질에 대한 문제도 있지만, 사용 환경에 맞지 않는 콘텐츠 형식이기 때문입니다. 예를 들어 모바일 환경에서 사용자는 문서 형식의 콘텐츠보다는 동영상 같은 콘텐츠를 선호한다고 합니다. 때문에 사용자 중심 접근으로 콘텐츠를 다시 설계해야 한다고 강조하고 있습니다(이전 책에서는 토픽 중심의 글쓰기를 강조했는데 이제는 그것만으로 모든 요구를 충족할 수 없다는 이야기입니다. 물론, 여전히 중요하지만 말이죠).
Our roles as technical writers are evolving as quickly as the products that we write information for. Because we develop embedded assistance, the timing and ways that we work with our extended teams have changed. We are more involved with product design and user interface development, which means that we must be involved earlier than ever in the development cycle.
이 책이 출판된 시기에는 아직 UX 라이팅이 번성(?) 하기 전입니다. 이제 막 역할이 정의되고 UX 라이터라는 직군이 생겨나기 시작했을 때입니다. 때문에 Embedded assistance 작업을 테크니컬 라이터가 해야 한다는 인식이 강했던 시기입니다. 그래서 3판에서는 Embedded assistance에 대한 예제나 설명이 많이 추가됐습니다. 1장에서 왜 우리가 이런 내용을 추가했는지 설명해주는 것이 아닌가 싶습니다(문서 기반의 매뉴얼만이 테크니컬 라이터의 영역이라는 생각이 강한 시절이었으니깐요. 물론 지금도 다른 이유로 마찬가지구요).
아쉽게도 저자들의 기대와 달리 UX 중심의 제품이 늘어나면서 좀 더 전문적인 영역인 UX 라이팅이 세력을 키울 수 있었고, 테크니컬 라이팅의 역할은 줄어들었습니다. 일부 교과서를 보면 테크니컬 라이터와 UX 전문가의 협업을 강조하고 있지만, 시장에서는 테크니컬 라이터를 더 이상 찾지 않는 결과를 낳게 되었죠. 아. 이렇게 설명하니 시작부터 너무 우울하네요 ^^
