솔루션 설계 전에 유저 스토리부터
솔루션 만들다 산으로 가는 일을 방지하는 데에 큰 도움이 됩니다
01. 전 '유저 스토리' 처음 들어봐요...
이직 후 5개월 정도가 지났습니다. 팀의 분위기나 일하는 방식도 사뭇 다른데요. 익숙했던 방법보다는, 옆 동료들을 보며 배우게 된 새로운 방법을 열심히 시도해보고 있습니다. 과거 기억을 떠올리면서 '아 그 때 이 방법을 알았더라면, 시도했더라면 더 좋았을텐데'라는 아쉬움이 가끔 떠오를 정도로- 새로 배우고 느끼는 것이 많아요.
그 중- 제품을 만드는 직업인으로 지내는 동안의 사고 방식에 꽤 오래 영향을 줄 것 같은 개념을 기록차 남겨둡니다. 바로 유저 스토리 입니다. 찾아보니 PM들이 자주 언급하는 용어라고 하는데, 부끄럽지만 전 이직하고 처음 들어본 말이에요. 입사 후 처음으로 주도한 기획 건에서 문제를 발견하고, 문제 해결을 위한 가설을 세워 프로덕트 디자이너 동료와 미팅을 진행했습니다. 가설 검증을 위한 솔루션 설계로 넘어갈 줄 알았는데 동료가가 아주 자연스럽게 유저 스토리부터 작성했습니다.
저에게 유저 스토리 개념을 소개해준 동료의 친절한 가이드유저 스토리란, 솔루션으로 충족시키고자 하는 사용자의 니즈를 사용자의 관점에서 작성한 문장입니다. 목적에 맞게 적당히 편집해서 사용하면 되는데요, 일반적으로는 누가 / 무엇을 / 왜 하고 싶은지 로 구성된 문장입니다.
ex. 사용자는 관심있는 피부과를 구분하고 싶다. 상담신청 전에 피부과 정보를 다시 확인하고 싶기 때문이다.
02. 유저 스토리의 좋은 점
회고와 성장을 좋아하는 직업인들 사이에 있다보면 참 여러 방법론을 배울 기회가 생기는데요, 사실 저는 경험의 부족함 때문인지 아직 그렇게 유용성에 공감되는 방법론이나 관점을 배운 적이 크게 없었어요. 그런데 유저 스토리는 정말 좋은 도구라고 느꼈습니다. 이유는 2가지입니다.
(1) 스펙 최소화 과정에서 사용자 니즈를 해치지 않을 수 있다
제품을 만들다보면 여러 이유로 스펙을 줄여야 합니다. 실험 비용 효율화를 위해 이미 줄인 스펙을 더 최소화해야 할 일이 생기죠. 리소스 분배, 일정 관리 등등의 다양한 이유로요. 이 때 우리가 갖고 있는 게 유저 스토리가 아니라 기능의 집합이라면, 결국 일부 기능을 자르면서 MVP를 좁혀나가게 됩니다. 저도 이런 일이 종종 있었어요. 위에 썼던 문장을 다시 가져와볼게요.
유저 스토리
- 사용자는 관심있는 피부과를 구분하고 싶다. 상담신청 전에 피부과 정보를 다시 확인하고 싶기 때문이다.
이 유저 스토리에 기반해 다양한 솔루션이 나올 수 있을텐데- 일단은 피부과 '찜' 기능이라고 예를 들어보겠습니다. 사실 찜 / 북마크 기능을 떠올리는 건 유저 스토리 작성 없이도 가능한 일이었을 겁니다. 관심있는 정보를 저장하거나 구분할 때 사용자가 익숙해하는 도구이니까 제품 메이커들도 머릿 속에 어느 정도 염두하고 있는 솔루션이지요.
만약 유저 스토리가 없다면, 우리는 스펙 최소화 과정에서 '찜을 넣어 말아'를 고민하고 있을 겁니다. 스펙을 줄이기 위해 "어쩔 수 없이" 찜을 뺀다면 사용자는 관심있는 피부과를 구분하고 싶은 니즈를 우리 제품에서 충족시킬 수 없을 것이고요. 하지만 유저 스토리가 있다면, 찜 말고도 관심있는 피부과를 구분할 다른 방법을 찾게 됩니다. '최근 본 병원'만 모아서 보여주거나, 병원 발품용 메모를 남길 수 있게 하거나 등등. 스펙만 아웃해야 하는데 사용자 니즈까지 같이 아웃시키는 일을 방지할 수 있습니다. 실제로 제작 과정에서 이걸 체감하면서 저는 유저 스토리 라는 도구에 대한 신뢰를 크게 가질 수 있게 되었어요.
(2) 산으로 가게 될 때 사용자 니즈를 환기시킬 수 있다
제품을 만들다보면 산으로 가게 될 때가 있습니다. 저는 특히 기획과 제작 사이에 시간 텀이 길 때 그렇더라고요. 이미 저는 다른 기획건의 결정에 정신이 팔려(?)있고, 과거에 기획했던 것 기반으로 제작 요청을 드리면서- 원래 우리가 풀려고 했던 사용자의 문제 보다는 기획서 자체에 몰입하게 되는 아쉬운 현상을 몇 번 경험해보았어요.
그 때 유저 스토리가 있다는 게 정말 든든했습니다. 이 기획건에 대한 모두의 기억이 희미해졌을 때 즈음- "우리 이거 왜 만들려고 했지? 무슨 문제 풀려고 했지?"를 가장 빠르게 환기시키는 건, 기획서 내에 적혀있는 배경이나 문제정의가 아니라 유저 스토리 였습니다. 이걸 적시에 다시 떠올리지 못하면- 원래 의도와는 전혀 다른 솔루션을 만들어서 모두가 벙찌는 상황이 발생하기도 하더라고요.
"어드민에 검수 기능이 필요해 안 해"가 아니라 관리자(사용자 유형 중 하나가 되겠죠)가 플랫폼 게시 전에 법무 리스크를 관리하고 싶어 해 안 해, 를 떠올리면서 사용자 중심의 고민을 하는 데에도 큰 도움이 되었습니다.
03. 유저 스토리, 앞으로 더 잘 쓰고 싶은 이유
제 스쿼드는 '가설'과 '솔루션 설계' 사이에, 가설 검증을 위해 달성 필요한 유저 스토리를 작성하는데요. 다른 스쿼드는 PRD 자체를 유저 스토리로 갈음 (대신 더 구체적으로 작성) 하거나 제품의 스펙 문서를 유저 스토리 모음으로 대체하기도 하더라고요. 제품의 복잡도를 고려해 적절히 사용하면 정말 유용한 도구인 것 같습니다.
요즘 사내 데이터 분석가께서 주도해주시는 그로스해킹 북스터디에 참여 중인데요. 아래 책을 읽고 있어요.
스터디 시작에 말씀해주셨던 것처럼 방법론보다는 관점, 애티튜드에 대해서 느끼는 바가 더 많은 스터디인데- 책을 읽다보니 이런 문장이 있더라고요. "서비스는 기능이 아니라 가설의 집합이다." 인상적이어서 메모도 해두었습니다. 결국 우리가 만드는 기능은 도구이지, 그 자체가 목적이 아니라는 것을 함의하고 있겠지요. 유저 스토리가 필요한 것도 같은 맥락이라고 생각합니다. 기능은 사용자의 니즈를 충족시키거나 문제를 해결할 때 유용하지 그 자체로는 자기만족 그 이상의 의미를 갖기는 어려울 것이에요. 목적과 도구를 구분하는 것이 언제나 좋은 결과를 가져다주는 건 아니지만 적어도 타율을 높이는 데에는 도움이 되리라 생각합니다.
배울 점이 많은 봄, 뿌듯한 5월은 요렇게 마무리해봅니다.
총총
