Ryan Young은 스트라이프 테크니컬 에디터입니다. 스트라이트에서 사용자 피드백을 가지고 어떻게 문서화를 개선했는지 설명합니다. 스트라이프 문서는 사용자가 피드백을 제공할 수 있는 기능을 지원합니다. 이런 피드백을 기반으로 사용자가 작업을 수행하기 위해 필요한 다양한 기능을 추가하고 있습니다. 그럼에도 계속 사용자의 불만은 늘어갔습니다. 그래서 피드백을 천천히 들여다보기 시작했습니다.
그중 하나가 "너무 많은 옵션(Too many options)"을 제공한다는 것이었습니다(문서 시스템의 기능을 이야기하는 건 아니고 제품 자체에서 다양한 옵션을 제공하는데 그런 옵션 설명이 흩어져있다는 것입니다). 그래서 사용자가 필요한 작업을 수행하기 위해 살펴봐야 하는 문서의 내용이 한 곳에 있지 않고 여러 곳에 흩어져 있게 됩니다. 그런데 이런 설명들이 일관성이 없어서 비슷한 기능 같은데도 설명이 다른 경우가 있고 옵션에 따라 작업 방식이 달라지는 경우도 있다고 합니다. 독자 입장에서는 내가 필요한 API를 어떻게 선택하고 사용해야 하는지 혼란스러운 상황이 된 거죠.
다른 하나는 "사용자가 활용할 수 없는 정보가 너무 많다(Too much information users can't utilize)"는 것이었습니다. 문서 중간중간에 고급 사용자들에게 필요한 다양한 정보를 추가했는데 단순히 특정 기능만 필요한 사용자가 문서를 읽을 때 이런 정보들이 방해가 된다는 것이었습니다.
"활용할 수 있는 정보가 너무 많다"와 이어지는 내용 같은데 문서에서 다루는 "범위(대상 독자)를 너무 넓게 잡거나 좁게 잡는(Wrong scope: too broad or too specific)" 경우입니다. 애매한 범위의 문서는 독자가 원하는 답변을 찾는데 어려움이 생기는 요인이기도 합니다.
"너무 기술적이다(Too technical)"는 최초 문서가 개발자를 대상으로 기획되었기 때문에 그런 것 같습니다. 하지만 제품이 성장하면서 전문 개발자가 아니더라도 제품을 사용하는 부류가 생겨났고 이들에게는 코드로 시작하는 문서가 부담스럽다는 의견이었습니다.
2021년도 문서를 보면 스트라이프의 중점 기능인 Payments를 가장 앞에 내세우고 있습니다. 실제 코드를 사용해서 API를 활용하는 가이드를 제시하는 것입니다. 하지만 제품 사용자 중에서 코드를 모르거나 익숙하지 않은 이들이 늘어나면서 코드를 모르더라도 그냥 가져다 붙이거나 좀 더 간단한 방법으로 제품을 바로 사용할 수 있는 가이드가 필요했습니다.
그래서 현재 시작 페이지를 보면 사용자가 가장 많이 찾는 작업을 전면에 내세우고 있습니다. 우선순위를 보면 No-code 항목이 첫 번째입니다. 해당 페이지를 가보면 문서 내에서 몇 가지 옵션을 선택해서 바로 사이트에 붙일 수 있는 코드를 복사해 가져가거나 순차적으로 설명하는 내용으로 구성되어 있습니다. 코드를 어떻게 하고 개발을 어떻게 하고 이런 내용은 전혀 없습니다.
"적절한 정보를 제공하지 않는다(Not the right information)"는 문서 자체가 잘못된 내용을 전달하는 건 아니고 사용자에게 필요한 정보가 누락된 것을 의미합니다. 문서를 작성할 때 여러 가지로 사용자가 어떤 방식으로 접근할 것인지 고민하고 만드는데 제품이 성장하다 보면 그런 예측된 경로에서 벗어나는 경우가 생길 수 있는 것이죠.
"어디서부터 시작하고 어디로 가야 할지 모르겠다(Not Clear where to start, where to go next)"는 정보 아키텍처의 문제인데 요즘에는 검색 시 AI를 사용하는 경우가 늘어나고 있고 딱 원하는 질문에 대한 답을 잘 찾아주고 있어서 점점 희미해질 수 있는 영역이긴 합니다. 그럼에도 문서 하단에 관련된 문서 링크를 추가해 주는 것은 사용자가 어디로 가야 할지 잘 알려주는 좋은 방식이긴 합니다.
피드백을 살펴보면서 대형 쇼핑몰을 떠올렸다고 합니다. 쇼핑몰은 다양한 카테고리가 뒤섞여 있어서 원하는 곳을 찾기 힘든데 이럴 때 도움이 되었던 것이 지도였다고 합니다. 문서를 읽을 때 사용자가 겪는 어려움은 쇼핑몰을 처음 방문할 때와 비슷하고 그렇다면 문서에서 지도를 제공하는 것이 문제가 아닐까 생각했다는 거죠.
사용자에게 제공할 정보를 수준 단위로 구분했습니다.
High level content는 쇼핑몰 디렉터리처럼 제품에 익숙하지 않은 사용자가 원하는 정보를 쉽게 찾을 수 있도록 제공하는데 집중합니다. 예를 들면 인덱스 페이지, 랜딩 페이지, 개요 같은 것들이죠.
Low level content는 개발자를 위한 문서들입니다. 통합 가이드, 빠른 시작 가이드, 레퍼런스 문서 같은 것들입니다.
그리고 middle level content가 필요합니다. 일종의 다리 역할을 하는 콘텐츠입니다. 개발자가 특정 작업을 바로 수행할 수도 있지만 전체적인 내용을 확인하고 어떤 부분의 작업이 필요할지 판단할 수 있는 콘텐츠가 필요하다는 것이죠. 마치 쇼핑몰의 층별 안내도 같은 역할입니다. 예를 들면 통합 사례, 작업 사례 문서, 콘셉트 문서 같은 것들이죠.
no code 콘텐츠는 사용자가 실제 수행할 작업 단위로 전체 프로세스를 설명하고 중간에 더 상세한 정보로 이동할 수 있게 제공합니다. 대부분의 경우에는 하고자 하는 작업이 비슷하기 때문에 작업을 설명한 콘텐츠에서 이를 해결할 수 있었습니다. 물론 모든 사용자가 만족한 것은 아니었습니다. 작업을 다루는 콘텐츠의 형식이 일관성 있게 만들었고 사용자가 어떤 문서에서도 같은 결과를 기대할 수 있게 구성했습니다.
각 수준을 좀 더 적절한 이름으로 구분했습니다. Orientation, Decision, Implementation.
Q&A
- 피드백은 어떻게 수집하나요?
기본적으로 좋아요, 싫어요를 선택하고 선택한 것이 따라 추가 의견을 남길 수 있는 기능을 제공합니다.
보통 사용자는 부정적인 감정에 피드백을 남기기 때문에 싫어요를 선택할 때 직접적인 의견을 남기는 것을 많이 개선하고 있습니다. 경우에 따라서는 사용자 장비에 원격으로 접근해서 어떤 문제가 있는지 살펴보기도 합니다.
실제 문서 하단에서 좋아요 또는 싫어요 선택 시 아래와 같은 추가 선택 항목이 나옵니다. 객관식으로 나열된 질문은 딱히 도움이 되지 않습니다. 예를 들어 내용이 부정확하다고 체크했다고 하더라도 뭐가 부정확한지 전혀 알 수 없기 때문이죠. 문서의 내용이 아주 간단하고 하나의 내용만 담고 있다면 그 내용을 다시 체크해서 알 수 있겠지만 그렇지 않다면 답변이 담고 있는 범위가 너무 넓어지는 겁니다.
발표에서 소개한 피드백을 보면 상당히 구체적입니다. 아마도 "Another reason"을 선택하고 작성했거나 다른 채널을 통해 접수된 내용일 겁니다. 주로 싫어요! 일 경우가 대부분 일거고 이렇게 구체적으로 내용을 남겨주면 운영자 입장에서는 화가 날 수도 있지만 도움이 됩니다.
