✍ 기획자의 글쓰기 시리즈 [📝문제를 미리 생각해보게 하는 3가지 스토리텔링 단계] (👀간단 요약) 우리가 일상적으로 사용하는 서비스와 제품에도 매력적인 스토리가 있다. 이번 포스팅에서는 전 세계적으로 많은 사람들이 이용하는 서비스인 Facebook에 담긴 스토리텔링을 분석해보고자 한다. 📌 페이스북의 스토리텔링 ✓ Concept Story : 서비스의 Core Concept과 Value Positioning을 제시하기 위해 사용한다. 거시적으로 서비스의 콘셉트와 서비스가 갖고 있는 가치를 소개하는 것에 목적을 둔다. -이 서비스는 누구를 위해 존재하는가? -서비스를 필요로 하는 사람들은 어떤 문제를 갖고 있는가? -그들의 목적은 무엇인가? -이 서비스는 무엇인가? -이 서비스를 필요로 하지 않는 사람이 있다면 그 이유는 무엇인가? -경쟁자보다 우리의 서비스가 나은 점은 무엇인가? -무엇이 문제를 해결하기 위한 가장 쉬운 해결책인가? (가상의 피트니스 서비스) fitCounter의 경우에 주인공의 문제는 '현재 건강 관리가 잘 되고 있지 않다.'이다. 주인공의 꿈은 자연히 '건강 관리를 잘 하고 싶다.'가 된다. 하지만 장애가 발생한다. 이미 유튜브에 상당 수의 피트니스 관련 동영상이 존재하기 때문에 돈을 내고 fitCounter를 구매할까? 하는 장애이다. fitCounter의 운영진들은 해결책을 찾아내기 위해 유튜브 피트니스 영상을 보았다. 생각보다 퀄리티가 좋지 않았으며 한 번에 시청하기에는 너무 재생 시간이 길었다. 또한 불특정 다수를 상대로 하는 것이다 보니 자신의 개인화된 피트니스를 제공하지 못하였다. fitCounter의 운영진들은 유튜브 영상의 문제를 곧 자신의 해결책으로 삼았으며 많은 사람들이 fitCounter 서비스 서브스크립션을 시작했다. ✓ Origin Story : 서비스에 대해 한 번쯤 들어본 사람이 어떻게 하면 서비스를 사용할 수 있게 만들까?를 설명하는 스토리이다. 가장 중심이 되는 것은 장애물 표시로 보이는 '위기'의 극복이다. 페이스북의 경우 많은 친구들을 하나씩 친구 초대하는데 시간이 오래 걸린다는 것이 위기였고, 당시 주소록 연동, 한 번에 추가 할 수 있는 기능을 만들었다. 자신이 친구 추가를 요청했는데 거절당했을 시에 기분이 좋지 않을 수 있다는 걱정을 하기도 하는데, 페이스북은 자동 친구 추천 기능을 해결책으로 제시했다. 또 친구에게만 공개하기 옵션 등을 활용하기도 했다. ✓ Usage Story : 말 그대로 사용자가 서비스를 사용하는데 필요한 스토리이다. 앞선 두 스토리보다 비중이 높다. 주목해야 할 점은 일차원적 해결책이 능사가 아니라는 것이다. 모든 해결책은 그를 가로막는 장애물이 존재한다. 즉 해결해야만 하는 문제가 아닌 그 문제의 해결책을 도입하는 것에도 장애가 발생한다. 트위코라는 가상의 네트워킹 애플리케이션이 있다. 그런데 근래에 사용자들로부터 사진 필터 기능을 추가해달라는 피드백이 들어오고 있다. 당신이 만약 트위코의 UX 디자이너 혹은 PM이라면 어떻게 할 것인가? 일차원적 해결책은 필터 기능을 추가하는 것이다. 그런데 눈치 채지 못한 문제가 여럿 존재한다. 개발 리소스 부족, 앱 용량 증가, 데이터 소모량 증가 등이 그 것. 가상의 PM은 유명한 사진 수정 어플인 PHODAK(가정)에서 사진을 수정하면 트위코로 바로 공유할 수 있는 기능을 추가하기로 한다. PHODAK 역시 트위코에 사진을 공유하기 위해 자사의 어플을 설치해준다면 일거양득이 된다. 또한 개발진들은 PHODAK의 공유하기 기능에 트위코의 API만 추가하면 되므로 시간이 많이 걸리지 않는다. 사용성 스토리는 계속해서 생겨난다. 해결책을 찾아가는 스토리는 조직을 하나의 목표에 집중하게 만든다. (👋중요한 이유가 뭔가요?) 여전히 글 쓰는 것은 어렵지만, 성격이 다른 글들을 5년 넘게 꾸준히 발행하면서 배운 점이 있다면 '뼈대'를 잡는 일이 훨씬 쉬워졌다는 것입니다. 얼마 전 코멘트한 '프로덕트 스펙 문서 제작(https://news.publy.co/comments/8149)'과도 같은 맥락인데요. 어떤 기능을 추가하거나 개선하거나 또는 아예 새로운 프로젝트를 진행함에 있어 글로 충분히 써보며 고민할 시간을 갖게 되었습니다. 물론 정해진 시간 내 써야 하지만요. 이 서비스를 누가 쓸까? 첫 사용과 재사용에 있어 이 사용자가 머뭇거리는 지점은 무엇일까? 자주 쓰면서도 불편을 느끼는 것이 있다면 무엇일까? 그 때 어떤 해결책이 필요할까? 위 소개 된 3가지 단계만큼 체계적이진 않더라도 서비스를 알게 되어 한 번 써보고 계속 써보는 일련의 과정에 대해 글로 쭉 써볼 수 있다는 건 기획의 뼈대를 만드는 것과 같을만큼 정말 중요한 일이 되었습니다. 처음엔 화면 만드는게 좋아서 일단 화면부터 만들고 봤어요. 저렇게 뼈대를 만들고 시작해도 무수히 많은 수정이 필요한데, 화면부터 무턱대고 만들었으니 저는 물론 함께 하는 구성원들의 혼란은 이로 말할 수 없었죠. 전 본문에도 언급된 '사용자 스토리'가 퍼르소나, 고객 여정 맵 보다 훨씬 정교한 기준을 잡아줄 수 있다고 생각해요. 말이 되는 시작점이 되어 준다는 점도 좋고요.