같은 질문이 세 번째로 올라오면 대부분의 운영자는 멤버들이 글을 읽지 않는다고 결론짓습니다. 더 쓸모 있는 결론은 답이 사람들이 찾는 자리에 없다는 것입니다.
“고정 게시물에 있잖아요”는 모든 소프트웨어 팀이 한 번쯤 해 본 변명의 커뮤니티 버전입니다. 기능은 분명히 있습니다 — 다만 마법의 주문을 알고 있어야 했을 뿐입니다. 사실이기는 합니다. 그리고 변명이 되지는 않습니다.
반복되는 질문은 데이터입니다
세 번 올라온 질문은 게으른 멤버 세 명이 아닙니다. 세 사람이 각자 따로 걸려 넘어진, 하나의 끊어진 길입니다.
그래서 이것은 여러분이 얻을 수 있는 가장 값싼 리서치입니다. 설문에 답해 줄 사람도, 인터뷰에 응해 줄 사람도 필요 없습니다 — 커뮤니티가 묻지도 않았는데, 그것도 공짜로, 무엇을 찾아내지 못하는지 정확히 알려 주고 있으니까요. 이걸 성가신 일로만 취급하는 운영자는 평생 받아 볼 유일한 무상 사용성 테스트를 내다 버리는 셈입니다.
2주 동안 목록을 만들어 보십시오. 전에 답한 적 있는 질문에 또 답할 때마다 한 줄씩 적어 두십시오. 2주가 끝나면 커뮤니티의 발견성이 어디서 무너지는지를 우선순위대로 정리한 목록이 손에 남습니다. 그것도 피해 당사자들이 직접 작성한 목록이.
무언가를 넣어 두는 곳은 사람들이 찾아보는 곳이 아닙니다
서로 다른 두 가지 문제인데, 거의 모든 운영자가 첫 번째만 풉니다.
구조는 분류의 문제입니다. 이건 어느 스페이스에 속하는가, 공개로 둘 것인가, 언제 보관 처리할 것인가. 운영자의 멘탈 모델이고, 잘 짜인 구조는 실제로 도움이 됩니다. 하지만 머릿속에 질문 하나를 들고 들어온 멤버는 여러분의 분류 체계를 구경하러 온 것이 아닙니다. 그 사람은 아주 구체적인 행동 하나를 하고 있고, 문제는 그 행동이 답에 가서 닿느냐입니다.
완벽하게 구조화된 커뮤니티가 완전히 길을 잃게 만들 수도 있습니다. 구조는 넣는 일에 최적화되어 있고 발견성은 꺼내는 일에 최적화되어 있기 때문입니다. 두 번째는 첫 번째에서 저절로 따라 나오지 않습니다.
멤버가 실제로 하고 있는 일
많아야 네 가지 정도이고, 각각 여러분에게 원하는 것이 다릅니다.
| 멤버가 하고 있는 일 | 필요한 것 | 보통 벌어지는 일 |
|---|---|---|
| 있다는 걸 아는 특정 답을 찾는 중 | 자기 말과 맞아떨어지는 검색 | 멤버는 자기 말로 입력하는데, 콘텐츠는 여러분의 말로 적혀 있습니다 |
| 여기가 뭐 하는 곳인지 궁금한 상태 | 누가 봐도 분명한 출발점 하나 | 대화가 한창인 피드 한복판에 떨어집니다 |
| 지난주에 본 것을 다시 보러 돌아옴 | 스크롤 말고 돌아가는 길 | 게시물 400개 아래에 묻혀 있습니다 |
| 물어봐도 될 곳인지 가늠하는 중 | 누군가는 답한다는 증거 | 답 없는 질문을 보고 그냥 떠납니다 |
이 중 검색 문제는 첫 번째뿐입니다. 나머지 셋은 검색하지 않아도 눈에 보이는 것들이 답합니다. “그냥 검색하세요”가 결코 온전한 해법이 되지 못하는 이유가 이것입니다.
고정은 분류 체계가 아닙니다
고정은 운영자라면 누구나 제일 먼저 집어 드는 도구이고, 대략 네 번째 항목쯤에서 작동을 멈춥니다.
고정 하나는 “이건 피드보다 중요하다”고 말합니다. 고정 다섯 개는 아무 말도 하지 않습니다. 이제 멤버는 그중 어느 것이 자기 것인지 알아내려고 다섯 개를 다 읽어야 하는데, 그건 애초에 피하려던 일이니까요. 더 나쁜 건 고정이 스스로 만료되는 법이 없다는 점입니다. 기한이 지난 것을 직접 내려 주지 않으면 고정 목록은 서서히 3월에 무엇이 중요했는지를 캐내는 발굴 현장이 되어 갑니다.
고정은 정해진 작은 예산처럼 다루십시오 — 두세 개, 그 이상 늘리지 않는 것으로. 네 번째를 더한다는 건 기존 것 중 무엇이 더는 그 자리에 있을 이유가 없어졌는지 정하는 일입니다. 그 결정이 도저히 불가능하게 느껴진다면, 고정하려던 그것은 아마 어딘가 영구적인 자리에 놓여야 할 물건입니다.
질문이 올라온 자리에서 답하십시오
본능적으로는 사람들을 올바른 자리로 보내고 싶어집니다. 하지만 대개 더 나은 수는 답을 틀린 자리로 가져오는 것입니다.
누군가 리소스 스페이스에 이미 정리돼 있는 내용을 채팅에서 묻습니다. “리소스에 있어요”는 그 사람에게 검색 한 번을 더 시키고, 질문에는 작은 벌칙이 따라붙는다는 걸 가르칩니다. 두 줄로 답해 주고 “다음에 찾기 쉽게 스페이스에도 올려 둘게요”라고 덧붙이면 30초가 들고, 원래 있던 것보다 더 잘 색인된 답이 하나 생깁니다.
“아까 말씀드렸다시피”라는 말이 나오려 하면 멈추고, 그 내용을 옮기십시오. 그 표현은 여러분이 분류 체계를 고치는 게 아니라 변호하고 있다는 꽤 믿을 만한 신호이고, 멤버는 그럴 뜻이 없었어도 가벼운 핀잔으로 듣습니다.
사람들이 부르는 이름으로 이름을 붙이십시오
발견성 실패의 대부분은 어휘의 실패이고, 그 단어를 고른 사람 눈에는 보이지 않습니다.
여러분은 스페이스 이름을 ‘리소스’로 지었는데, 사람들은 “템플릿”을 찾습니다. ‘3분기 프로그램 업데이트’라는 제목으로 글을 썼는데, 사람들은 “다음 콜 언제”로 검색합니다. 운영자는 안쪽에서 이름을 붙입니다. 만들 때 자기에게 말이 되던 단어를 쓰고, 그러고 나서 왜 아무도 못 찾는지 의아해합니다. 멤버의 단어가 언제나 맞는 단어입니다. 타이핑하는 사람이 그 사람이니까요.
해법은 둘 다 쓰는 것입니다. 제목에는 그들의 표현을, 본문에는 여러분의 표현을 넣으십시오. 아니면 그냥 같은 것을 다른 말로 두 번 말해도 됩니다. 검색은 반복을 싫어하지 않고, 결과 목록을 훑는 멤버도 마찬가지입니다.
모든 것은 밀려납니다. 그러니 무엇을 다시 올릴지 정하십시오
피드는 컨베이어 벨트입니다. 일부러 다시 끌어올리지 않는 것은 실려 나가고, 그 ‘사라짐’은 운영자의 예상보다 빨리 옵니다 — 보통 일주일 안에.
커뮤니티가 커질 때 조용히 무너지는 지점이 바로 여기입니다. 3개월 차에 이곳을 가치 있게 만들어 준 답들은 9개월 차에도 여전히 그 자리에 있고, 여전히 맞는 말이며, 사실상 보이지 않습니다. 누가 지운 게 아닙니다. 피드가 그냥 앞으로 간 것이고, 새 멤버들은 그런 게 있는 줄도 모릅니다. 아카이브를 그저 쌓아 두는 데서 그치지 말고 물어보면 답이 나오는 것으로 만들어야 하는 진짜 이유가 이것입니다.
오래 가는 것 몇 개를 골라, 일정을 정해 의도적으로 다시 올리십시오. 반복한다고 사과할 필요는 없습니다. 처음 온 사람은 본 적이 없고, 이미 본 사람은 0.5초 만에 스크롤로 지나갑니다. 같은 말을 또 한다는 민망함은 오직 여러분만 치르고 있는 몫입니다.
소프트웨어가 말해 줄 수 있는 것과 없는 것
추측하지 않아도 되는 유일한 영역인데, 들여다보는 사람이 거의 없습니다.
Mateflow에는 멤버용 검색이 있습니다 — 커뮤니티 전체에서도, 스페이스 하나 안에서도 — 그리고 관리자 쪽에는 분석 → 검색 화면이 있습니다. 이 화면이 스스로 달고 있는 부제가 “멤버가 무엇을 검색하는지, 찾지 못한 것은 무엇인지”입니다. 여기서는 전체 검색 수와 고유 검색자 수, 검색자당 평균, 그리고 전반적인 검색 → 클릭 비율을 보여 줍니다. 여기에 각 단어마다 클릭률이 붙은 인기 검색어 표와, “아무 결과도 없었던 검색어 — 보완할 콘텐츠 공백”이라고 대놓고 적어 둔 결과 없음 검색어 목록이 결과 없음 비율과 함께 따라옵니다. 그 목록이 비어 있을 때는 “결과 없는 검색이 없어요 — 훌륭한 커버리지예요”라고 말합니다.
그중 두 숫자가 나머지를 다 합친 것보다 값집니다. 결과 없음 검색어는 멤버들이 자기 어휘로 여러분의 콘텐츠 백로그를 대신 써 주고 있는 것입니다. 그리고 클릭률이 낮은 인기 검색어는 결과 없음 검색어보다 더 나쁩니다 — 검색했고, 결과도 나왔는데, 그중 어느 것도 답처럼 보이지 않았다는 뜻이니까요. 콘텐츠가 비어 있는 문제가 아니라 이름을 잘못 붙인 문제입니다. 정직한 한계는 이것이 검색만 기록한다는 점입니다. 검색할 생각조차 못 한 멤버, 대신 채팅에 물어본 멤버, 아무 말 없이 떠난 멤버는 이 데이터에 아예 없습니다 — 그러니 이 수치는 발견성 문제의 크기를 재는 자가 아니라 그 바닥선으로 다루십시오.
5분 테스트
지난주에 가입한 사람에게 특정한 세 가지를 찾아 달라고 부탁하고, 옆에서 지켜보되 아무 말도 하지 마십시오.
찾을 수 있다고 자신하는 것들로 고르십시오. 다음 콜 일정, 가장 자주 반복되는 질문의 답, 그리고 여러분이 자랑스러워하는 오래된 글 하나. 그런 다음 조용히 계십시오. 도와주고 싶은 충동은 머리가 아니라 몸으로 옵니다 — 거기에 지는 순간, 얻을 수 있었던 유일한 데이터가 사라집니다.
그 사람이 제일 먼저 어디로 가는지 보십시오. 거의 언제나 여러분이 짐작한 곳이 아니고, 그 관찰 하나가 이 글의 나머지 전부보다 값질 때가 많습니다. 여러분 머릿속의 지도와 그들이 실제로 쓰고 있는 지도의 차이가 거기서 드러나니까요.
하지 말아야 할 세 가지
발견성 문제에 콘텐츠를 더 얹어서 답하지 마십시오. 아무도 첫 번째 FAQ를 읽지 않았다고 두 번째 FAQ를 쓰면, 멤버에게는 답을 못 찾을 곳이 두 군데 생기고 여러분에게는 최신으로 유지할 것이 두 개 생깁니다.
“여기서 시작하세요” 글 하나를 만들어 두고 끝났다고 여기지 마십시오. 도움은 됩니다. 그리고 낡습니다 — 그 글은 그때의 커뮤니티를 위해 쓰였고, 아무도 다시 읽지 않습니다. 온보딩은 문서가 아니라 흐름입니다.
한 번에 전부 다시 짜지 마십시오. 대대적인 개편은 모두의 머릿속 지도를 초기화합니다. 어디에 뭐가 있는지 이제 막 익힌 멤버들까지 포함해서요. 가장 많이 반복된 질문 세 개만 고치고 거기서 멈추십시오.
정말로 콘텐츠가 없는 경우
때로는 그것이 진짜로 없기도 하고, 그 차이를 가려낼 줄 아는 편이 낫습니다.
신호는 일관성입니다. 사람들이 검색하고, 물어보고, 아무도 어디를 가리켜 주지 못한다면 그건 발견의 문제가 아니라 콘텐츠의 공백이고, 해법은 그 내용을 한 번, 제대로, 영구적인 자리에 쓰는 것입니다. 이 두 실패는 운영자가 앉은 자리에서 보면 똑같이 생겼습니다 — 둘 다 반복 질문의 얼굴로 도착하니까요 — 하지만 필요한 대응은 정반대이고, 잘못 찍으면 한 달을 날립니다.
쓰기 전에 먼저 확인하십시오. 답이 이미 있는데 발견되지 않는 상황이라면, 더 나은 답을 쓴다고 해결되지 않습니다. 찾을 수 없는 답이 하나 더 늘어날 뿐이고, 이제 그 둘은 서로 말이 어긋나기 시작합니다.
결론
발견성은 플랫폼의 기능이 아닙니다. 여러분이 쓴 단어와 멤버가 썼을 단어 사이의 간격이고, 두 번씩 답해야 하는 질문의 수로 측정됩니다.
그러니 반복 질문 목록을 계속 쌓고, 고정 개수에 상한을 두고, 사람들이 묻는 자리에서 답한 다음 그 답을 옮기고, 여러분의 어휘가 아니라 멤버의 어휘로 이름을 붙이고, 오래 가는 것들을 민망해하지 말고 다시 올리십시오. 그리고 사람들이 무엇을 검색했고 무엇을 찾지 못했는지 직접 읽어 보십시오 — 커뮤니티에 무엇이 빠져 있는지를 알려 주는 가장 짧고 정직한 목록이고, 들여다보는 데 드는 것은 아무것도 없습니다.