모든 것이 정상 작동하지만 사용자는 여전히 혼란스러워합니다: SaaS 팀이 놓치고 있는 것
Source: Dev.to
Your users don’t care about your docs, roadmap, or changelog.
They care about one simple thing:
Can I figure this out without friction?
Everything else, including how well your docs are written or how polished your roadmap looks, is secondary if the overall experience feels disconnected.
우리가 틀린 점
초기에 우리는 기대되는 모든 요소를 다 갖췄다고 진심으로 믿었습니다:
- 상세한 문서
- 깔끔한 API 레퍼런스
- 공개 로드맵
- 피드백 제출 양식
- 꾸준히 유지되는 릴리즈 노트
내부에서는 완전하고 잘 구조화된 느낌이었지만, 외부에서는 혼란스러웠습니다.
우리가 보지 못한 단절
실수는 미묘했습니다. 우리는 빌더로서 우리가 생각하는 방식에 따라 모든 것을 정리했으며, 문제를 해결하려고 할 때 사용자가 생각하는 방식은 고려하지 않았습니다.
| 카테고리 | 사용자 관점 |
|---|---|
| Surface | Purpose (from our perspective) → 목적 (우리 관점에서) |
| Docs | Learning how things work → 작동 방식을 배우기 |
| Roadmap | Seeing what is planned → 예정된 내용 보기 |
| Changelog | Tracking what changed → 변경 사항 추적 |
| Feedback | Requesting features → 기능 요청 |
논리적으로 보이지만, 사용자는 이렇게 카테고리별로 생각하지 않습니다. 그들은 종종 무언가를 수행하려고 할 때 순간 순간에 생각합니다.
사용자가 실제로 생각하는 방식
사용자는 “오늘 로드맵을 확인해 보자” 라는 생각으로 깨어나지 않는다. 그들의 여정은 다음과 더 가깝다:
- “이걸 어떻게 하나?”
- “이게 가능한가?”
- “불가능하다면, 계획에 있나요?”
- “이미 이와 관련된 무언가를 출시했나요?”
이 질문들은 서로 연결되어 연속적으로 발생하며, 별개로 일어나지 않는다.
경험이 끊기는 지점
개발자가 특정 문제를 해결하려 문서를 열었을 때 제한에 부딪히고 다음과 같이 질문한다고 상상해 보세요:
“이 제한이 영원히 존재하는 건가요, 아니면 현재 해결 중인가요?”
그 순간 흐름이 끊깁니다. 문서를 떠나 로드맵을 열고, 관련 내용을 찾으려 애쓰고, 아마 변경 로그를 확인하고, 그래도 답을 찾지 못하면 피드백을 제출합니다.
| 단계 | 행동 | 위험 |
|---|---|---|
| 1 | 문서 읽기 | 상황이 명확함 |
| 2 | 로드맵으로 전환 | 상황이 흐려지기 시작함 |
| 3 | 변경 로그 확인 | 더 많은 노력 필요 |
| 4 | 피드백 제출 | 이탈 가능성 높음 |
각 단계마다 마찰이 발생합니다—제품이 나빠서가 아니라 경험이 여러 곳에 분산돼 있기 때문입니다.
왜 문서 개선이 문제를 해결하지 못했는가
우리는 문서를 계속 개선했습니다—더 명확하게, 구조를 개선하고, 예시를 추가했지만—전체적인 경험은 크게 개선되지 않았습니다. 실제 격차는 문서, 로드맵, 피드백, 업데이트 사이에 있었으며, 문서 자체 안에 있던 것이 아니었습니다.
우리의 사고를 바꾼 전환
다음과 같이 묻는 대신:
“우리 문서를 어떻게 개선할 수 있을까?”
우리는 다음과 같이 물었다:
“사용자가 무언가를 해결하려 할 때 우리 제품 지식을 어떻게 탐색하는가?”
그 단 한 번의 전환이 우리가 모든 것을 접근하는 방식을 바꾸었다.
대신 시도한 방법
- 문서는 실제 제품 결정과 연결되었습니다.
- 로드맵은 격리되지 않고 맥락 속에서 보였습니다.
- 피드백은 실제 사용 사례와 연결되었습니다.
- 업데이트는 사용자가 요청한 내용에 다시 참조되었습니다.
목표는 더 많은 콘텐츠를 만드는 것이 아니라 그 사이의 격차를 줄이는 것이었습니다. 이 접근 방식은 결국 우리에게 CandyDocs 를 만들게 했습니다.
실제로 개선된 점
가장 큰 개선은 내부 효율성이나 속도가 아니라 단순히 사용자들이 덜 혼란스러워졌다는 것이다.
| 이전 | 이후 |
|---|---|
| 사용자는 어디로 가야 할지 알아야 했다 | 사용자는 한 흐름으로 탐색할 수 있었다 |
| 빈번한 막다른 길 | 원활한 네비게이션 |
| 무엇이 존재하고 무엇이 오는지 불분명 | 가시성 및 명확성 향상 |
| 업데이트를 자주 놓침 | 업데이트를 자연스럽게 발견 |
작은 하지만 중요한 깨달음
이전에는 우리의 일이 정보를 게시하는 것이라고 생각했습니다. 이제는 다르게 보고 있습니다: 우리의 일은 사용자가 결정을 내리고 마찰 없이 앞으로 나아가도록 돕는 것입니다. 이는 해결해야 할 매우 다른 문제입니다.
대부분의 팀이 과소평가하는 것
이것들을 별개의 레이어로 생각하기 쉽습니다:
- Docs는 학습을 위한 것입니다
- 로드맵은 투명성을 위한 것입니다
- 체인지로그는 업데이트를 위한 것입니다
사용자에게는 이 모든 것이 하나의 목표입니다:
제품에 대한 이해
그 이해를 위해 여러 도구와 컨텍스트를 오가야 한다면, 보이지 않는 마찰을 추가하게 되며 이는 시간이 지날수록 누적됩니다.
아직도 파악 중인 한 가지
모든 것을 한 곳에 모아두는 것이 항상 완벽한 답은 아닙니다. 별도의 도구들은 강력하고 유연하지만, 그 도구들을 직접 연결해야 한다는 전제가 따릅니다. 대부분의 팀은 이를 완전히 수행하지 않으며, 우리도 마찬가지였습니다.
다른 사람들은 어떻게 처리하고 있는지 궁금합니다
SaaS 제품을 구축하는 분들을 위해:
- 오늘날 문서, 로드맵, 피드백이 연결되어 있다고 느끼시나요?
- 아니면 별개의 레이어로 존재하나요?
- 사용자들이 그 사이에서 길을 잃는 것을 본 적이 있나요?
그리고 더 중요한 질문:
- 맞춤 페이지까지 포함해 모든 것을 한 곳에서 관리하는 것이 유용하게 느껴지나요, 아니면 불필요하게 제한적이라고 생각하시나요?
우리에게 한 가지 변화를 가져다준 것이 있다면, 바로 이것입니다: 우리는 “더 좋은 문서를 어떻게 쓰나요?” 라는 질문을 멈추고,
“사용자들이 마찰 없이 우리 제품을 어떻게 이해하나요?”
라는 질문을 시작했습니다.
그 질문이 바로 우리가 처음에 CandyDocs 를 만들게 된 이유입니다.