✍ 기획자의 글쓰기 시리즈
[📝 내가 쓴 릴리즈 노트는 왜 안 읽힐까?]
(👀 간단 요약)
📌 읽기엔 너무 긴 릴리즈 노트
✓ 릴리즈 노트란 앱 또는 웹과 같은 소프트웨어의 개선사항, 즉 주요 업데이트 사항을 요약한 문서
✓ 서비스의 버그 수정 건이나 신규 기능의 추가 건, 기존 기능의 삭제 건 등 서비스상 일어나는 다양한 변경점 포함
✓ 서비스를 만드는 입장에서는 고객들에게 전달하고 싶은 말이 많을 수도
✓ 그럼에도 불구하고 릴리즈 노트는 최대한 핵심적인 내용만 담아 간결하게 작성되어야
✓ 시간을 내어 업데이트 사항을 읽으러 온 고마운 유저들을 지루하게 만들어서 돌려보내지 말자
📌 지나치게 기술적인 내용
✓ 어떤 글이든 읽는 이, 즉 독자를 고려하여 작성되는 것이 바람직
✓ 서비스 입장에서 릴리즈 노트를 읽는 대상은 누구일까
✓ 내부의 사용자 들일 수도 있지만, 더 많은 경우에는 외부에 있는 일반적인 유저들
✓ 기술적인 용어로 작성된 릴리즈 노트는 유저 입장에서 어떤 가치를 얻을 수 있는지 이해하기 어려움
✓ 내부의 히스토리 관리는 별도로 하되 릴리즈 노트는 항시 유저 관점에서, 사용자 친화적인 언어로 작성
📌 참고할 만한 정보나 링크를 전혀 포함하지 않는 경우
✓ 참고할 만한 정보가 없는 릴리즈 노트만큼 유용한 것이 없다
✓ 소소한 버그 수정'과 같은 릴리즈 노트가 대표적인 예시
✓ 유저가 그 글을 읽음으로써 얻을 수 있는 정보 효용 가치가 0에 수렴
✓ 단순히 줄글만 있는 릴리즈 노트로 유저의 액션이나 반응을 유도하는 데에는 한계
✓ 전달하고자 했던 내용을 유저들이 잘 소화시킬 수 있는 형태로 전달
✓ 이후 행동으로까지 파생될 수 있도록 디테일을 챙길 필요가 있음
📌 간결하고 명확하게, 일관된 언어로 작성한다
✓ 최대한 핵심적인 내용만 간추려서 명확하고 일관된 언어로 전달
✓ 서비스에서 장바구니를 '수강바구니'라고 칭하고 있다면 수강바구니라는 단어를 일관적으로 사용
✓ 상황에 따라 장바구니로 쓰거나 carts로 쓰는 등, 읽는 이로 하여금 혼동을 주는 표현은 지양
📌 Call to Action을 포함한다
✓ 서비스를 이용하는 유저에게 충분한 정보를 제공할 수 있도록 미디어나 참고 링크가 포함된 형태로 작성
✓ 신규로 배포되었거나 개선된 기능에서 의외의 효과(반응)를 거둘 수 있을지도
✓ 유저의 CS 역시 함께 인입될 수 있으므로 문의할 수 있는 공식 창구나 서포트봇을 함께 안내하는 것이 중요
📌 한 가지 채널로만 전달하지 않는다
✓ 릴리즈 노트의 내용이 동일해도 좋으니 한 가지 채널로만 배포하지 말자
✓ 서비스에서 뉴스레터나 대화형 봇이 있다면 해당 채널을 활용해서 최대한 많은 유저들이 원문에 도달할 수 있도록
✓ 여러 채널로 릴리즈 노트를 전달할 경우에는 분명한 이점이 있음
✓ SNS를 통해 전달하는 경우 유저들의 반응을 조금 더 적나라하고 손쉽게 '눈으로' 확인 가능
✓ 뉴스레터(이메일)를 통해 발송하는 경우, 서비스에 로그인하지 않은 유저들에게 접근 가능
📌 릴리즈 노트를 잘 쓰는 곳, 슬랙
1. 먼저 출시 버전과 날짜를 잘 기입하고,
2. 주요하게 변경된 내용이 무엇인지 잘 소개하고,
3. 버그 수정 건을 유저가 잘 이해할 수 있는 형태로 설명하고,
4. 참고할 수 있는 문서는 링크로 제공하며,
5. 서비스의 유쾌한 보이스톤을 잃지 않는다.