도움말 문서

기능이 열 개일 때는 문의가 와도 감당이 됩니다. 담당자가 답장에 조작 순서를 적어 보내면 그걸로 끝납니다. 그런데 같은 질문이 한 주에 스무 번씩 들어오기 시작하면 이야기가 달라집니다. 답장은 매번 처음부터 다시 쓰이고, 쓰는 사람에 따라 설명이 조금씩 달라지고, 지난주에 보낸 답장에 적힌 메뉴 이름이 이번 배포로 이미 바뀌어 있습니다.

페이지덱에서도 그랬습니다. 수아가 오전에 연 지원 티켓 여섯 건 중 네 건이 "팀원에게 편집 권한을 어떻게 주나요" 였습니다. 티켓은 접수된 문의 한 건을 뜻하는 단위입니다. 수아는 두 건에 예전 담당자가 보냈던 답장을 복사해 붙였는데, 그 답장에 적힌 메뉴 이름이 석 달 전 화면 기준이라 고객이 "그런 메뉴가 없는데요" 하고 되물었습니다. 같은 설명을 여섯 번 쓰는 것보다, 여섯 번 다 조금씩 다르고 그중 둘은 틀린 설명이라는 쪽이 더 큰 문제였습니다.

도움말 문서는 이 답장을 한 번만 쓰고 여러 번 쓰이게 만든 장치입니다. 고정된 주소에 한 벌을 걸어 두면 설명이 하나로 모이고, 화면이 바뀌었을 때 고칠 자리도 하나입니다. 가르치는 사람이 그 자리에 함께 있지 않아도 되고, 읽는 사람이 열 명이든 만 명이든 드는 비용이 같습니다. 담당자가 시간을 정해 직접 진행하는 교육 세션과 갈리는 지점이 여기입니다.

문서 한 편은 보통 다음 여섯 조각으로 이루어집니다. 조각마다 빠졌을 때 어떤 문의가 돌아오는지가 정해져 있습니다.

1. 제목. 고객이 검색창에 실제로 칠 말로 짓습니다. 제품 내부에서 부르는 이름인 "권한 관리" 보다 고객이 하려는 일인 "팀원에게 편집 권한 주기" 가 검색에 걸립니다.
2. 대상과 조건. 누가 할 수 있는 작업인지 첫머리에 밝힙니다. 관리자만 가능한 설정인데 그 말이 없으면, 일반 멤버가 네 단계를 따라 하다 마지막에서 버튼을 못 찾고 문의를 씁니다.
3. 단계. 번호를 붙인 조작 순서이고 한 단계에 동작 하나만 넣습니다. "설정에서 팀을 고른 뒤 권한 탭에서 편집을 선택합니다" 는 두 단계로 쪼갭니다. 한 줄에 동작이 둘 들어가면 읽는 사람이 어디까지 했는지 놓칩니다.
4. 화면 이미지. 버튼이 어디 있는지는 글보다 그림이 빠릅니다. "오른쪽 위" 라고만 적으면 창 크기에 따라 위치가 달라져 고객이 다른 버튼을 누릅니다.
5. 안 될 때. 흔히 막히는 지점 두세 개와 그때 확인할 것을 답니다. 이 조각이 빠진 문서는 단계를 따라 하다 어긋난 고객을 그대로 문의로 돌려보냅니다.
6. 마지막 갱신 날짜. 고객이 이 설명을 믿어도 되는지 판단하는 근거입니다. 2년 전 날짜가 붙어 있으면 읽던 사람이 중간에 닫습니다.

여섯 중 셋째와 다섯째가 실제 품이 가장 많이 드는 자리입니다. 단계와 막히는 지점은 그 기능을 직접 눌러 보면서 쓰지 않으면 나오지 않습니다.

쓰는 사람은 회사 크기에 따라 달라집니다. 초기에는 그 기능을 만든 사람이 씁니다. 스펙을 쓴 프로덕트 매니저나 개발한 사람이 동작을 가장 정확히 알기 때문입니다. 문서가 수백 건이 되면 테크니컬 라이터라는 전담 직무가 생깁니다. 제품 설명 글을 쓰는 것이 본업인 사람이고, 문서마다 제각각이던 용어와 말투를 한 벌로 맞추는 일까지 맡습니다.

페이지덱은 아직 전담이 없어서 둘이 나눠 씁니다. 지현이 기능을 내보내면서 단계까지 초안을 쓰고, 수아가 문의를 받으면서 실제로 고객이 막히는 지점을 뒤에 붙입니다.

읽는 사람은 두 종류입니다. 첫째는 고객입니다. 첫 문서부터 차례로 읽는 고객은 없고, 대부분 막힌 순간에 검색으로 한 편에 곧장 들어옵니다. 그래서 문서 한 편은 그 한 편만 읽어도 말이 되어야 합니다. "앞 문서에서 만든 팀에서" 같은 문장을 쓰면 앞 문서를 안 읽고 들어온 사람은 거기서 멈춥니다.

둘째는 내부 담당자입니다. 수아는 답장에 설명을 다시 쓰는 대신 문서 링크를 붙여 보냅니다. 문서가 고객용이면서 동시에 상담의 재료인 셈이고, 이 쓰임 때문에 문서의 정확도가 문의 처리 속도에 바로 연결됩니다.

"이 질문 이번 주만 네 번째예요. 도움말 문서 하나 쓰는 게 빠르겠어요."

같은 답장을 반복해 쓰느니 한 번 써서 고정해 두자는 제안입니다.

"문서 링크 보내 드렸는데 다시 물어보셨어요. 3번 단계가 지금 화면이랑 달라요."

문서가 있긴 한데 배포 이후 갱신되지 않아 오히려 고객을 헤매게 했다는 보고입니다.

"다음 주에 설정 화면이 바뀌니까 손봐야 할 문서 목록부터 뽑아 주세요."

배포 전에 영향받는 문서를 찾아 두자는 뜻으로, 화면이 바뀌는 배포에서 흔히 오가는 말입니다.

페이지덱이 권한 설정 화면을 갈아엎던 주에 이 셋이 한 번에 나왔습니다. 지현이 배포 일정을 공유하자 수아가 권한을 다루는 문서 일곱 편을 뽑아 왔고, 그중 넷은 화면 이미지만 바꾸면 되지만 셋은 단계 자체가 달라진다는 것이 그 자리에서 드러났습니다. 셋을 먼저 고치고 배포 당일 아침에 교체하기로 정했습니다.

기존 고객에게 무엇이 바뀌는지 알리는 변경 안내도 같은 주에 나갔습니다. 안내는 바뀐다는 사실을 알리고 문서는 바뀐 뒤의 방법을 알려 주므로, 안내문 안에서 문서로 링크가 걸립니다. 순서가 뒤집혀 안내가 먼저 나가고 문서가 옛날 화면 그대로면, 안내를 읽고 찾아온 고객이 곧장 틀린 설명을 만납니다.

문서를 만들어 두면 문의가 저절로 준다고 생각하기 쉽습니다. 문의가 많아서 문서를 쓰기 시작했으니 자연스러운 기대입니다. 실제로는 고객이 그 문서에 닿아야만 줄어듭니다. 검색에 안 걸리는 제목을 달았거나 제품 안 어디에도 링크가 없으면, 문서는 있는데 문의 건수는 그대로입니다. 그 상태로 반년이 지나면 문서를 쓴 쪽은 "써 봐야 소용없다" 는 결론을 내리고 다음 문서를 안 씁니다. 실제로 손봐야 할 것은 문서의 내용이 아니라 문서에 닿는 경로입니다.

한 번 쓰면 끝나는 자산으로 보는 것도 흔합니다. 글이라서 그대로 남아 있을 것 같지만, 문서가 가리키는 화면은 계속 바뀝니다. 틀린 문서는 없는 문서보다 나쁩니다. 없으면 고객이 바로 문의를 쓰지만, 틀린 문서는 고객이 그 설명대로 해 보고 안 되는 시간을 먼저 쓰게 만들고 그 뒤에 문의가 옵니다. 그래서 문서 수를 늘리는 계획에는 갱신할 시간도 같이 잡아 둡니다.